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This  report  is  one  of  a  sat  of  five  volumes  produced  to  document  the  combat 
assessment  methodologies  and  automated  features  of  the  Combined  Arms  Combat 
Development  Activity  (CACOA)  JIFFY  III  War  Gaming  process,  developed  to  support 
TRA00C  SCORES  scenario  development  and  force  evaluation  efforts.  This  report 
provides  a  concise  explanation  of '‘now  to  game  JIFFY.  The  automated  features 
of  the  gaming  process  and  the  gamers  interface  are  exemplified  through  a  sample 
run. jrThe  other  four  volumes  In  the  set  are  the  Executive  Summary  (Vol  I), 
Methodology  (Vol  II),  the  classified  data  and  their  sources  (Vol  III),  ana  the, 
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FOREWORD 


The  Jiffy  III  War  Game  model  was  used  In  the  development  of  the 
SCORES  Europe  III  scenario,  which  provides  the  combat  developments 
community  with  a  common  base  of  assumptions,  threat  forces,  weapons, 
organizations,  terrain,  and  tactics  for  the  1986  timeframe.  The  1977 
version  of  Jiffy  was  extensively  modified  and  Improved  for  the  Europe 

III  work.  This  report  documents  the  Jiffy  III  model  as  used  for 
Europe  III  and  Incorporates  significant  portions  of  the  CACDA  Jiffy 
War  Game  Documentation,  Technical  Manuals  TR  2-77,  TR  3-77,  and  TR 
4-77,  originally  published  In  1977.  This  report  documents  all  the 
changes  and  improvements  completed  through  March  1980. 

There  are  five  volunes  of  Jiffy  III  War  Game  documentation.  The 
first  volune  Is  the  Executive  Sunmary.  Volume  II  Is  the  Methodology, 
which  describes  the  overall  Jl^fy  III  War  Game  methodology  Including 
detailed  descriptions  of  the  combat  assessment  equations.  The 
computer  calculates  th:  attritions  based  on  these  equations.  The 
unclassified  portions  of  the  data  are  given  in  Volime  II.  Volume  III 
contains  classified  data  as  required  for  the  Jiffy  III  model.  Volume 

IV  Is  the  Users  Manual,  which  contains  a  discussion  of  the  manual 
aspects  and  the  automated  features  of  the  gaming  process  and 
exemplifies  the  relationship  between  them  through  some  sample  runs. 
Valune  V,  the  Programmers  Manual,  consists  of  descriptions,  and 
FORTRAN  code  of  all  programs  and  routines  associated  with  the  Jiffy 
III  game. 

This  report  was  compiled  principally  by  Dr.  Channlng  L.  Pao,  Dr. 
Robert  J.  Schwabauer,  Mr.  Timothy  J.  Bailey,  Mr.  James  H.  Kennlngton 
and  Mr.  William  D.  Relph.  The  compilers  want  to  acknowledge  the 
SCORES  gaming  staff . orf  the  Combined  Arms  Combat  Development  Activity 
who  served  as  consultants  during  the  methodology  Improvement. 
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ABSTRACT 


This  report  Is  one  of  a  set  of  five  volumes  produced  to  document 
the  combat  assessment  methodologies  and  automated  features  of  the 
Combined  Arms  Combat  Developments  Activity  (CACDA)  Jiffy  III  war 
gaming  process.  The  Jiffy  process  was  originally  developed  to  support 
the  TRADOC  Scenario  Oriented  Recurring  Evaluation  System  (SCORES) 
scenario  development  and  force  evaluation  efforts.  In  1978,  the  1977 
version  of  the  Jiffy  was  extensively  modified  and  improved  to  support 
Europe  III  scenario  gaming.  This  report  documents  the  Jiffy  model 
used  for  that  gaming  through  March  1980.  Volume  II  of  this  report 
contains  the  methodologies  used  in  the  automated  routines  of  the  Jiffy 
III  Game.  An  unclassified  data  base,  which  was  developed  for  test  and 
demonstration  purposes.  Is  presented  In  Volume  II.  The  classified 
data  used  In  the  Jiffy  III  Game  during  secure  production  runs,  and 
their  sources,  are  published  separately  as  Volume  III  to  keep  the 
methodology  volume  unclassified.  The  other  three  volunes  In  the  set 
are  the  Executive  Summary  (Volume  I),  the  Users  Manual  (Volume  IV), 
and  the  Prograomers  Manual  (Volume  V). 
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CACOA  JIFFY  WAR  GAME  USERS  MANUAL 

1.  PURPOSE  AND  SCCPE.  The  purpose  of  this  manual  is  to  provide  a  clear, 
concise  explanation  of  "how  to  game  Jiffy."  It  is  intended  to  provide 
information  to  personnel  familiar  with  war  gaming  but  not  familiar  w>th 
specific  Jiffy  procedures.  The  Jiffy  model  continues  to  be  moclfied  or 
improved  for  new  scenarios/studies.  This  report  incorporates  all  f!ie 
changes  and  improvements  completed  through  October  1979;  however,  the 
general,  procedure  has  not  changed. 

2.  ■  JIFFY  DESCRIPTIONS. 

a.  General .  Jiffy  is  a  two-sided,  computer-assisted,  open  war  game. 

Players  manipulate  forces,  using  maps  and  performance  indicators  to 
simulate  ground  combat.  Jiffy  is  an  Interactive  war  game  capable  of 
addressing  indirect  fire,  armor/antiarmor,  armed  helicopter/ air  defense, 
dismounted  infantry,  and  minefield  play.  (If  the  security  condition 
warrants  Jiffy  can  be  run  in  a  batch  mode;  however,  some  delay  in  response 

must  be  expected.)  Resolution  Is  normally  battalion  for  Blue  and  regiment 

for  Red.  A  rate  of  advance  routine  determines  time  to  advance  over 
terrain  or  the  distance  advanced  in  a  given  time. 

b.  The  Critical  Incident.  Jiffy  divides  a  day  of  battle  into 

critical  incidents  (Cl).  The  time  length  of  a  Cl  is  variable;  it  should 
be  long  enough  to  permit  evaluation  of  selected  parameters  nf  battle,  yet 
not  so  lortg  as  to  lose  the  significance  of  major  actions.  A  good  rule  of 
thumb  Is  to  have  CIs  4  to  6  hours  long.  This  length  gives  a  good  period 
of  time  for  battles  to  take  place,  yet  allows  the  gamer  to  influence  the 
overall  battle  with  his  decisions.  If  the  action  is  light,  longer  CIs  may 

be  used  in  order  to  decrease  the  real  time  to  battle  time  ratio.  The 

greater  the  Influence  of  gamer  judgnent,  the  shorter  will  be  the  Cl  and 
the  larger  the  real  time  to  battle  time  ratip.  Critical  Incidents  should 

not  be  so  short  (less  than  2  hours)  as  to.  Imply  that  Jiffy  is  a, high  - 

resolution  game,  which  It  Is  not  designed  to  be.  From  experience,  a 
6-hour  critical  Incident  for  a  corps  level  battle  allows  gamers  to 
Influence  the  battle  but  still  utilizes  the  computational  ability  of  Jiffy 
for  a  relatively  quick  turnaround.  If  a  division  or  lower  is  to  be  , 
investigated,  CIs  might  be  slightly  shorter.  The  concept  of  a  Cl  Is 
Important  to  Jiffy  since  the  entire  game  Is  basically  a  sequence  of 
critical  Incidents.  The  setup  of  each  critical  incident  follows  the  same 
procedures,  as  outlined  below. 

3.  PERSONNEL  REQUIREMENTS  AND  RESPONSIBILITIES. 

a.  General . 

(1)  A  Jiffy  Game  requires  about  nine  personnel,  at  least  seven  of 
whom  should  be  military.  If  a  game  Is  extremely  detailed,  additional 
manpower  may  be  required.'  Personnel  are  required  In  two  main  categories, 
control  team  and  gamer  teams,  as  follows: 


(a)  Team  chief. 

(b)  Control  team. 

1.  Chief  controller  (military). 

2.  Assessment  officer  (military). 

(c)  Blue  gamer  team. 

1_.  Team  commander  (military). 

2.  Assistant  gamer  (military). 

3.  Statistician. 

(d)  Red  gamer  team. 

L  Team  commander  (military). 

2.  Assistant  gamer  (military). 

2*  Statistician. 

(2)  It  must  be  emphasized  that  this  gaming  staff  Is  only  that 
which  is  required  to  play  the  game  interactively.  Analytical  support, 
computer  programming  support,  and  secretarial  support  are  not  considered 
here.  Likewise,  if  a  particular  field  of  military  expertise  or  computer 
program  analysis  Is  needed,  it  must  be  provided  from  an  outside  source. 

b.  Team  Chief  and  Chief  Controller.  The  team  chief  is  responsible 
for  the  overall  gaming.  He  selects  experienced  military  gamers  and 
supervises  the  performance  of  the  entire  gaming  staff  to  insure  proper 
preparation,  gaming,  and  reporting.  After  the  team  chief,  the  chief 
controller  should  be  the  person  who  is  the  most  knowledgeable  of  overall 
military  operations  on  the  gaming  staff.  It  Is  his  responsibility  to 
insure  that  the  gaming  maintains  a  logical  flow.  Since  Jiffy  is  primarily 
an  open  game,  the  controller  must  Impose  constraints  on  the  Blue  and  Red 
gamers  to  Insure  their  actions  are  correct  in  a  military  sense,  given  the 
intelligence  information  they  could  expect  to  possess.  Additionally,  the 
chief  controller  must  insure  that  actions  not  computerized  within  Jiffy 
are  played  logically.  For  example,  a  unit  that  has  been  heavily  attritsd 
cannot  be  brought  up  to  strength  immediately  and  committed  because  some 
organizational  time  Is  needed.  It  Is  the  chief  controller's 
responsibility  to  insure  that  the  game  produces  the  data  and  results  that 
are  needed  by  analytical  personnel  involved  In  a  particular  study.  , 

c.  Assessment  Officer.  The  assessment  officer  Is  the  person  who 
actually  plays  the  interactive  Jiffy  Game  on  the  terminal.  He  must  know 


both  the  logic  of  the  Jiffy  Game  and  the  tactical  feasibility  of  the 
maneuvers.  He  works  closely  with  both  the  chief  controller  and  the  gamers 
to  insure  the  correctness  of  all  actions.  During  the  course  of  a  ct 1 ti cal 
incident,  he  works  directly  with  the  Red  and  Blue  gamers  on  the  map  to 
define  sectors  and  forces  in  that  sector.  It  is  the  Red/Blue  commander 
who  determines  what  opposing  forces  face  each  other  In  the  Jiffy  model. 

He  then  Inputs  the  forces  and  various  parameters  for  each  sectu*  In 
Jiffy.  The  assessment  officer  must  be  capable  of  making  the  decisions, 
such  as  disengagement  criteria,  that  are  called  for  during  the  interactive 
mode.  He  is  responsible  for  working  closely  with  Red  ard  Blue  gamers  to 
insure  the  teams  receive  the  proper  effects  from  combat  and  that  the 
effectiveness  of  units  is  properly  maintained.  The  assessment  officer 
provides  a  written  narrative  describing  the  action  that  takes  place  in 
each  critical  incident.  The  chief  controller  is  responsible  for  the  data 
and  results,  but  It  is  the  assessment  officer  who  maintains  the  actual 
liaison  with  any  analytical  staff  to  Insure  the  game  is  accomplishing  its 
objectives. 

» 

d.  Chief  Gamer  (Red  or  Blue).  The  chief  gamer  is  responsible  for 
organizing  and  employing  his  forces.  His  position  is  that  of  commander  of 
his  forces  down  to  the  resolution  required.  He  must  be  able  to  maintain 
data  on  unit  effectiveness.  The  chief  gamer  develops  the  concepts  and 
provides  the  rationale  for  . all  maneuvers.  He  insures  the  map  situation  is 
current.  With  the  assessment  officer  he  determines  the  sectors  to  be  used 
in  each  Cl.  The  chief  gamer  provides  a  written  narrative  of  his  concept 
of  operation  and  the  rationale  behind  his  concept.  He  should  have  a’ 
thorough  knowledge  of  the  tactical  doctrine  used  by  his  forces. 

e.  Assistant  Gamer.  The  assistant  gamer  Is  concerned  primarily  with 

following  the  status  of  forces  on  his  side.  He  assists  the  assessment 
officer  with  the  initial  force  file  creation  for  the  game.  He  Insures  the 

forces  in  each  sector  are  at  proper  strength  and  all  necessary  forces  are 

included  in  a  sector.  He  keeps  his  chief  gamer  Informed  of  unit 
effectiveness  and  assists  ’in  maintaining  the  map  board.  He  is  responsible  • 
for  close  coordination  with  the  assessment  officer  concerning  the 
attrition  of  his  forces  during  a  critical  Incident.  The  assistant  gamer 
coordinates  the  replacement  policies  of  each  side.  In  other  matters  he 
assists  the  chief  gamer  as  directed. 

4.  METHODOLOGY. 

a*  General.  TV  methodology  for  playing  a  Jiffy  Game  may  be 
considered  in  three  major  phases:  preparation,  critical  incident  gaming, 
and  reports  and  results.  It  is  essential  to  maintain  a  proper  perspective 

throughout  this  procedure  to  Insure  Jiffy  Is  not  used  for  an  investigation 

beyond  its  capability.  The  decisions  made  by  the  commanders  are  a  major 
portion  of  the  entire  process  and  must  be  reflected  effectively  in  each 
critical  Incident.  The  overall  sequence  of  events  Is  summarized  in  . 
figure  1. 
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Figure  1.  Jiffy  war  gaming  process. 


b.  Preparation  Phase. 

(1)  The  preparation  phase  has  u-c  parts:  the  selection  and 
Implementation  of  the  general  scenario,  and  the  preparation  for  the 
specific  game.  The  general  scenario  part,  although  It  Is  a  prerequisite 
for  any  Jiffy  Game,  is  usually  done  outside  the  game  staff.  It  Includes 
Blue  and  Red  posture  at  the  start  of  the  game,  time  frame,  area  of 
operations,  weather,  and  objectives  of  the  game.  The  actual  preparation 
by  the  gamers  starts  with  the  receipt  of  the  general  scenario  and 
objectives  of  the  game.  In  the  initial  preparation  step  the  gamers 
prepare  the  map,  conduct  a  terrain  analysis,  and  array  the  opposing  forces 
on  the  map  as  they  would  be  positioned  at  the  start  of  the  game.  While 
the  chief  Blue  and  Red  gamers  are  developing  their  general  concepts,  the 
assistant  gamers  under  the  direction  of  the  assessment  officer  create  the 
TOE  force  structure  files  on  the  terminal.  This  step  entails  creation  of 
four  files: 

(a)  Standard  reference  code  (SRC)  file.  In  this  file 
weapons  are  grouped  under  an  SRC.  These  SRCs  are  the  basic  building  block 
for  the  entire  force.  They  may  be  platoon,  cor  :> any,  or  battalion  size, 
depending  on  the  resolution  required.  A  library  of  SRCs  has  been  built 
and  Is  available  for  use.  If  appropriate. 

(b)  Unit  file.  In  this  file  units  are  built  based  upon  one 
cr  more  SRCs.  The  units  will  generally  be  an  organizational  level  below 
the  resolution  desired.  This  gives  the  gamer  the  ability  to  play  part  of 
a  unit  separate  from  the  parent  unit. 

(c)  Parent  unit  file.  In  this  f  He,  parent  units  are  built 
based  upon  one  or  more  units.  This  parent  unit  will  be  the  organization 
at  the  level  of  resolution  desired  (usually  battalion  for  Blue  and 
regiment  for  Red). 

(d)  Force  file.  The  force  file  is  a  consolidation  of  the 
first  three  files.  This  file  Is  processed  by  the  Jiffy  game  during  the 
gaming  of  a  Cl.  It  contains  the  designation  of  each  unit  and  the  parent 
unit,  the  T-.t  Cl  the  unit  was  Involved  in  and1 Its  sector,  and  the  status 
of  all  the  weapon  systems  at  the  end  of  Its  last  Cl.  Additionally,  the 
current  effectiveness  of  each  unit  Is  maintained  In  this  file. 

(?)  A  detailed  exjmple  of  how  to  create  these  files  Is  contained 
In  appendix  A.  The  force  file  is  the  file  from  which  optional  displays  of 
parent  units,  units,  and  their  strengths  are  derived.  When  the  loading  of 
the  starting  forces  is  completed,  the  actual  dynamic  gaming  of  Jiffy  may 
take  place. 

c.  Critical  Incident  Phase.  The  critical  incident  phase  of  Jiffy  is 
the  major  portion  of  the  dynamic  gaming  process.  Reference  is  again  made 


to  figure  1.  The  Cl  phase  is  an  Interactive  process  involving  the  four 
main  steps  indicated  in  figure  1:  rate  of  advance,  attrition 
calculations,  relative  effectiveness, • and  Cl  analysis.  The  critical 
incident  analysis  and  the  overall  concept  of  the  operation  determine  if 
another  Cl  should  be  run.  This  procedure  continues  until  the  game  reaches 
some  predetermined  termination  point.  The  gaming  usually  starts  with  a 
meeting  of  the  entire  gaming  staff  in  a  gaming  room,  with  the  map  and 
overlays  showing  starting  positions.  At  this,  time  background  information 
and  general  concepts  are  briefed  for  both  sides.  The  remainder  of  this 
subparagraph  describes  the  steps  taken  each  time  a  critical  incident  is 
run. 


(1)  Sectors  defined.  The  chief  gamers  and  assessment  officer 
determine  from  the  map  board  and  the  commander's  intentions  where  battles 
take  place  and  what  forces  are  Involved.  This  process  In  essence  defines 
a  sector.  The  entire  FEBA  may  be  subdivided  into  sectors,  or  sectors  may 
be  designated  only  in  areas  where  some  action  is  to  take  place.  The  Cl  is 
played  In  Jiffy  sector  by  sector  with  no  interaction  between  sectors.  The 
sectors  may  vary  in  size  and  number  from  one  Cl  to  the  next.  Once  the 
sectors  have  been  defined  by  the  assessment  officer  and  chief  gamers,  the 
assistant  gamers  coordinate  with  the  assessment  officer  in  loading  the 
forces  for  that  sector.  Any  forces  that  would  affect  the  battle  and  are 
employed  In  that  sector  must  be  identified  to  Include  Infantry,  armor, 
artillery,  aviation,  and  air  defense  systems.  Specifically,  the  assistant 
gamer  from  each  side  must  insure  that  the  forces  in  the  force  file  are 
true  and  correct  as  a  result  of  any  replacements  that  might  have  arrived 
since  the  end  of  the  last  Cl.  If  not  he  must  access  the  force  file  and 
bring  a  particular  unit  up  to  strength..  This  is  accomplished 
Interactively  utilizing  the  file  handling  features  of  the  Jiffy  Game. 

This  force  file  update  should  be  done  prior  to  loading  forces  into  a 
sector  to  save  time. 

(2)  Force  loads.  After  the  terminal  has  been  logged  in,  and  the 
Jiffy  Game  **sessed  (see  appendix  B  for  th^s  procedure),  the  gamer  reaches 
the  DECISION  POINT.  The  interactive  game  centers  around  the  DECISION 
POINT.  Eleven  options  are  available  to  the  gamer: 

.  Load  forces  Into  a  sector. 

.  Calculate  rate  of  advance. 

.  Assess  combat. 

.  Apportion  combat  losses  to  units. 

.  Display  battle  statistics. 

.  Display  weapon  arrays. 

..  Add  SRCs  to  the  TOE  file. 

.  Restart  at  a  previously  gamed  Cl. 

.  tnd  game  and/or  update  HISTORY  file. 

.  Reset  element  array. 

.  Reset  terminal  output. 
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Forces  may  be  assigned  to  a  sector  by  assigning  the  parent  unit  (in  which 
case  all  units  in  that  parent  will  be  assigned)  or  by  assigning  specific 
units  from  a  parent  unit.  The  ability  to  assign  part  of  a  parent  unit  to 
one  sector  and  part  to  another  satisfies  the  condition  of  a  parent. unit 
being  engaged  by  more  than  one  opposing  unit,  which  allows  it  to  be 
engaged  at  different  intensities  of  combat. 

(3)  Rate  of  advance. 

(a)  Procedures.  After  the  forces  are  loaded  into  a  sector 
the  rate  of  advance  must  be  computed  next.  The  questions  that  the 
assessment  officer  must  answer  are  listed  in  figure  3-4  of  the  example  in 
appendix  8.  This  routine  must  be  completed  prior  to  running  any 
assessment  routines.  Basically,  the  rate  of  advance  routine  calculates  a 
total  firepower  ratio,  then  enters  a  table  for  the  given  posture  of 
opposing  forces.  If  time  is  held  constant,  then  distance  advanced  is 
computed;  if  distance  is  held  constant,  then  time  Is  Computed.  This 
routine  Is  essential  since  it  gives  the  closure  rate  of  ground  combat  for 
the  attrition  routines.  A  detailed  explanation  of  the  logic  and  equations 
used  in  the  rate  of  advance  is  found  in  the  CACDA  Jiff''  III  War  Game 
Volume  II. 

(b)  Gamer's  Inputs  and  considerations. 

.  Type  engagement— fortified/prepared/hasty  defense,  delay, 
withdrawal,  and  meeting  enegagement. 

.  Attacker  posture— front  attack,  single  invelopmerit,  and 
double  envelopment. 

.  Type  terrain— open,  rolling,  hilly,  and  mountainous. 

.  Visibility. 

.  Mines/Barriers. 

.  Mounted/dismounted  attackers. 

.  Our at Ion  of  attack.  - 

.  Smoke— type,  self-generated  and  frontage  to  determine 
percent  obscured  for  both  sides. 

.  EW— mrniber  missions  available,  and  target  priority  for  both 
sides. 


(4)  Attrition  calculated. 

(a)  Procedures.  The  assessment  officer  is  concerned  with 
five  major  attrition  i-outines  when  playing  the  Jiffy  Game:  indirect  fire, 
armor/antiarmor,  mine  warfare,  attack  helicopter/air  defense  and  infantry 
assault.  A  detailed  rationale  and  explanation  of  each  of  these  assessment 
routines  may  be  found  in  the  CACOA  Jiffy  III  War  Game,  Volume  II.  The 
descriptions  here  are  limited  to  an  explanation  of  the  interface  that 
takes  place  between  the  assessment  officer  and  the  program.  After  the 
rate  of  advance  has  been  calculated,  the  program  returns  to  the  DECISION 
POINT.  In  order  to  run  the  assessment  subroutines  a  "3''  must  be  entered 
from  the  terminal.  The  program  then  cycles  through  the  assessment 
subroutines  in  the  following  order: 

.  Tactical  aircraft. 

.  Indirect  fire. 

.  Minefields. 

.  Armor/ anti  armor. 

.  Dismounted  infantry. 

.  Attack  helicopter/air  defense. 

The  program  asks  the  gamer  If  he  wants  to  process  each  specific  routine. 

If  the  response  is  no,  that  routine  is  skipped.  If  the  response  is  yes, 
further  questions  are  asked  by  the  program.  In  each  case  the  questions 
require  the  Input  of  parameters  that  Influence  the  attrition  routines.  At 
the  end  of  each  attrition  routine  there  Is  the  option  of  deleting  the 
losses  from  the  weapon  system  array  in  that  sector.  If  everything  has 
progressed  satisfactorily  the  losses  may  be  subtracted,  and  the  program 
advanced  to  the  next  assessment  routine.  If  for  some  reason  the 
assessment  officer  wishes  to  replay  that  specific  attrition  routine,  he 
would  not  subtract  the  forces.  He  must  then  return  to  the  beginning  of 
the  cycle,  not  playing  those  assessment  subroutines  already  satisfactorily 
played,  until  he  again  reaches  the  subroutine  he  wishes  to  replay  and 
continue  from  there.  A  detailed  example  of  the  assessment  questions  is 
Included  In  appendix  3.  This  process  is  the  heart  of  the  Interactive 
games. 

(b)  Gamer's  Inputs  and  considerations.  The  assessment 
officer,  must  insure  that  the  parameters  put  into  the  game  accurately 
reflect  the  terrain,  posture,  and  tactics  of  the  force  Involved.  His 
military  judgment  and  coordination  with  both  team  chiefs  is  needed  to  make 
such  decisions  as  when  to  pull  out  of  a  defensive  position,  or  what 
intensity  of  artillery  Is  being  fired.  Close  coordination  between  the  ■ 
assessment  officer  and  chief  controller  may  be  required  here  to  Insure 
that  reality  Is  represented  as  closely  as  nosslble.  The  gamers'  inputs 
and  considerations  for  the  five  major  subroutines  stated  above  are 
summarized  as  follows: 

l.  Indirect  fire  subroutine: 
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.  Number  of  firing  batteries. 

.  Hours  of  fire  support. 

Type  of  mission— final  protective  fire, 
preparatory/counterpreparatory,  counterbattery,  AD 
suppression,  and  combat  support. 

.  Number  of  CLGP  missions. 

.  EM— number  of  missions  available  and  target 
priority  for  both  sides. 

.  Percent  of  smoke  firers  (degrades  other  fire 
missions}— number  of  batteries  available  and 
strength,  desired  smoke  frontage,  round 
capability,  and  importance  of  other  missions. 

2.  Minefield  subroutine: 

.  Meters  of  minefield  front. 

.  Mine  density  (per  square  meter). 

.  Fract4on  of  minefield  which  can  be 
bypassrj— deployment  of  units,  number  of  units, 
unit  missions. 

.  Meters  of  traffl cable  terrain— map  study  of  sector. 

.  Percent  of  force  entering  minefield— deployment  of 
units,  number  of  units,  unit  missions,  defender 
strength/status,  and  type  unit/strength. 

,  Type  of  minefield— conventional  (laid  mechanically 
or  manually)  and  FASCAM  (GEMMS  and  artillery). 

Armor /anti armor  subroutine: 

.  Number  sysucns. 

.  Type  of  engagement— fortified/ prepared/hasty 
defense,  meeting  engagement,  delay/withdrawal. 

.  Type  terrain— open,  rolling,  hilly,  and 
mountainous. 


.  Visibility. 


.  Target  range  and  percent  engaged— mission  of  both 
sides,  range  of  last  Cl  engagement,  terrain, 
avenues  of  approach,  unit  strength/mix  of 
vehicles/type  unit,  and  length  of  time  in  position. 

.  Smoke  and  dust— number  of  batteries  available  and 
strength,  round  capability,  and  importance  of 
other  fire  missions. 

4.  Infantry  subroutine: 

.  Tactics  employed— ambush,  fortified/prepared/hasty 
defense,  meeting  engagement,  and  delay/withdrawal. 

.  Forces  engaged— fr action  of  forces  and  sector, 
units  to  dismount,  unit  deployment/posture,  and  Cl 
length. 

.  Duration  of  combat. 

5.  Attack  helicopter/AD  subroutine: 

.  Weapons  control  status. 

.  .  .  Percent  of  AD  committed— terrain,  number  of 

systems,  tactical  deployment,  suspected  firing 
positions,  and  perceived  AH  threat. 

.  ADA  Target  priority. 

.  Helicopter  standoff  distance  and  type  AH  attack 
(autonomous/indirect)— mission,  terrain,  day  or 
night,  cell  composition,  AD  threat,  and  number  of 
AH/scouts  available. 

(5)  Losses  apportioned.  Once  the  attrition  routines  have  been 
played,  the  game  returns  to  the  DECISION  POINT.  In  order  to  apportion  the 
combat  losses  from  the  sector  to  the  proper  forces  In  the  force  file,  a  . 
•4"  must  be  entered.  After  the  "4"  has  been  entered,  the  combat  intensity 
of  any  unit  may  be  changed.  The  combat  Intensity  determines  the  amount  of 
losses  apportioned  to  each  unit..  If  one  unit  was  In  combat  less  than 
another  during  the  Cl,  It  Incurs  a  smaller  proportion  of  losses;  The 
specific  entries  for  given  conditions  of  combat  are  as  shown, in  table  1. 

The  routine  distributes  the  losses  to  the  units,  and  the  gamer  has  the 
option  of  seeing  the  new  force  structure  at  the  completion  of  the 
routine.  An  example  of  this  routine  is  in  figure  3-13  of  appendix  B. 
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Table  1.  Combat  intensity  entries  for  apportionment  routines. 


ENTER  FOR  THIS  STATUS 

0  Uncommitted  units 

1  Units  outside  of  direct  fire 

2  Reserve  units  committed  late 

3  Units  on  perimeter  of  MBA 

4  Urits  in  Main  Battle  Area 

5  Units  Hit  by  TACAIR 

(6)  Unit  effectiveness  determined.  Ouring  the  loss 
apportionment,  the  new  relative  unit  effectiveness  of  each  unit  is 
computed.  Simply,  the  unit  effectiveness  of  a  unit  is  the  ratio  of  its 
present  firepower  score  to  the  firepower  score  the  unit  started  with. 

This  computation,  output  on  the. Unit  Status  portion  of  the  STATUS  file 
(see  appendix  C),  combined  with  the  gamer's  knowledge  of  the  task 
organizations  should  be  sufficient  to  provide  a  base  for  the  military 
judgment  used  in  decisions  made  during  the  analysis  of  the  Cl. 

d.  Reports  and  Results  Phase.  The  final  phase  of  the  Jiffy  Mar 
Samlng  process  is  the  results  presented  and  the  reports  produced  from 
those  results. 

(1)  Results.  For  each  sector  there  are  two  types  of  information 
recorded.  First,  each  unit  gamed  In  that  sector  has  a  record  of  losses 
and  current  remaining  status  of  weapons.  These  unit  displays  also  Include 
the  relative  effectiveness  of  each  unit.  Each  unit  is  reported  separately 
and  the  aggregated  status  of  the  parent,  unit  is  reported  also.  Second, 
each  sector  has  statistical  tables  showing  loss  by  source  of  loss,  loss 
and  damage  distribution,  ammunition  expenditure,  and  killer  victim 
tables.  Additionally,  these  tables  are  aggregated  for  an  entire  critical 
incident.  A  detailed  description  of  the  output  from  Jiffy  is  given  In 
appendix  C. 

(2)  Reports.  '  The  content  of  the  game  report  may  vary  depending 
upon  the  objective  of  the  game.  However,  there  are  certain  areas  that  the 
report  should  contain  as  a  minimum.  There  should  be  a  narrative 
description  of  the  game  as  It  developed.  This  Is  usually  the  assessment 
officer's  portion  of  the -report.  The  rationale  for  gamer  tactics  and 
organizations  is  input  by  the  chief  gamers.  Finally,  insights  Into  force 
structures  (strength  and  deficiencies)  should  be  reported.  This  last  area 
may  be  expanded  or  contracted  depending  upon  the  purpose  of  the  game. 

e.  Special  Time  Saving  Features. 

(1)  Assessment  testing.  Although  the  Jiffy  war  gaming  process 
plays  unit  location  the  assessment  routines  in  the  Jiffy  program  do  not 
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take  this  into  account.  Before  assessment  begins,  the  Jiffy  program  puts 
all  the  weapon  systems  into  a  single  weapons  array.  This  is  one  reason 
why  the  program  is  Tow  resolution  and  why  judgment  and  military 
craftmanship  are  so  vital  to  the  Jiffy  war  gaming  process.  The  weapons 
array  can  be  set  directly.  This  Is  useful  for  sensitivity  testing  of 
software  modifications  and  data  changes. 

(2)  Review  of  previous  run.  Sometimes  many  n f  the  interactive 
answers  of  a  sequence  of  runs  are  very  similar.  The  user  can  review  and 
interact 1 vely  change  selected  answers  of  th*  last  run  and  let  the  program 
automatically  use  the  old  answers  that  are  appropriate  for  the  current  run. 

(3)  Reset  terminal  output  file.  The  user  can  decide  what  part  of 
the  Interactive  output  he  wishes  to  see  at  the  terminal.  This  can  be 
useful  when  running  Jiffy  at  the  terminal  from  a  file  of  answers  prepared 
In  advance. 

f.  General  Time  Saving  Features.  Two  time  saving  features  that  do 
not  require  new  decision  points  are  given  below. 

(1)  Master  answer  file.  The  answers  to  a  sequence  of  runs  (for 
example,  one  for  each  sector  of  a  C.I)  can  be  saved  on  a  single  file.  If 
regaming  of  the  Cl  Is  necessary  because  output  is  lost,  for  example,  this 
can  be  done  automatically  from  the  master  answer  file. 

(2)  Short  answer  file.  A  sector  can  be  played  with  a  partial 
answer  file  attached,  say,  through  the  rate  of  advance.  After  the  answers 
on  this  file  have  been  processed,  the  user  can  continue  from  that  point 
with  his  terminal  entries.  This  is  particularly  useful  In  debug  runs 
where  all  answers  to  a  certain  point  are  the  same  for  each  run. 

g.  Postprocessor.  The  output  from  Jiffy  gaming  Is  voluminous  and 
consists  of  detailed  unit  status  reports  and  game  reports.  All  these 
reports  pertain  only  to  a  critical  incident  (Cl).  The  postprocessor  is 
designed  to  provide  specified  game  output  reports  *s  well  as  cumulative 
game  output  reports.  The  format  of  the  loss  by  source-of-loss  tables  has 
been  expanded  to  give  losses  by  victim  weapon  system  category  In  addition 
to  victim  weapon  system  type.  The  victim  weapon  system  categories  are  the 
same  as  the  killer  categories.  The  postprocessor  will  enhance  analyst  and 
gamer  efficiency  and  save  time.  Some  of  the  specfic  outputs  and 
capabilities  from  the  postprocessor  are  shown  in  appendix  C. 
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SAMPLE  RUN  OF  FORCE  FILE  GENERATION  PROCESS 

A-l.  PURPOSE  AND  SCOPE.  The  purpse  of  this  appendix  Is  to  provide  the 

gainer  and  the  assessment  officer  step  by  step  procedures  for  the  creation 
of  a  file  of  forces  suitable  for  processing  by  the  Jiffy  Same.  An  example 
of  each  of  the  programs  used  to  generate  such  a  force  file  is  presented 
and  discussed,  in  turn,  below. 

A-2.  GENERAL.  Basically  three  files  are  created  to  define  units,  and  one 
file  is  created  on  which  the  data  of  the  other  three  files  are 
consolidated.  The  SRC  (standard  reference  code)  file,  the  UNIT  file,  and 
the  PARENT  file  are  the  three  files  used  to  define  the  weapons  of  SRCs, 
build  units  from  SRCs,  and  develop  higher  echelon  parent  units.  The  FORCE 
file  is  the  file  that  contains  all  the  information  of  the  three  files 
formatted  for  processing  in  the  Jiffy  Game.  Initially,  some  empty  files 
are  created  and  given  names.  In  the  example  presented  here,  the  files  are 
SRCFILE,  UNITFILE,  PARENTFILE,  and  FORCEFILE.  To  facilitate  processing, 
interactive  "call"  files  have  been  created  that  contain  the  control  Cards 
necessary  to  attach  the  proper  files  and  execute  the  programs.  In  the 
following  sample  runs,  the  alpha-character  responses  input  by  the  gamers 
are  smaller  than  the  letters  In  question  displayed  by  the  Jiffy  Game 
program.  Note,  however,  that  there  is  no  difference  between  a  gamer 
response  and  a  computer  display  for  numerals. 

A-3.  "CALL"  FILES.  The  sample  runs  presented  in  the  following  paragraphs 
are  initiated  by  the  use  of  "call"  files.  Listings  of  the  five  "call" 
files  used  for  processing  the  runs  in  this  document  are  given  in  figure 
A-l.  Each  of  these  files  contains  control  statements  that  accomplish 
three  basic  requirements  for  running  one  of  the  programs.  The 
requirements  are:  1)  connects  Input  and  output  as  required  for 
interactive  processing,  2)  attaches  the  program  and  all  the  files  the 
program  operates  on  (a  data  file  must  be  attached  as  CLDATA  before  the 
"call"  files' for  the  FORCE  program  or  the  Jiffy  Games  are  executed),  and 
3)  executes  the  program.  The  commands  contained  in  the  "call"  files  can 
be  entered  individually  from  the  console.  It  should  be  noted,  in  fact, 
that  some  operating  systems  may  not  allow  "call"  files,  in  which  case  the 
commands  would  have  to  be  Input  separately.  All  commands  and  1-0 
procedures  demonstrated  in  this  document  are  for  the  Control  Oata 
Corporation  (CDC)  6400/6500  multiprocessor  computer  at  Fort  Leavenworth, 
Kansas.  One  point  to  be  emphasized  is  that  the  local  file  names  for  the 
force-type  files  must  be  exactly  as  shown  In  figure  A-l  when  one  of  the 
programs  is  being  run.  For  example,  to  run  the  Jiffy  Game  program,  the 
FORCEFILE  must  be  attached  as  TAPE55,  the  SRCFILE  as  TAPE9,  and  the 
HISTORYFILE  as  TAPE8. 


SRC  CALL  FILE 


CONNECT, INPUT, OUTPUT. 

ATTACH , LGO , SRC8 IN , ID-SCORES ,MR*1 . 
ATTACH,TAPE9,SRCFILE, ID-SCORES. 
LGO. 


UNIT  CALL  FILE 

CONNECT, INPUT, OUTPUT. 

ATTACH, LGO, UNIT3IN, ID-SCORES, MR-1. 
ATTACH, TAPE9,SRCFILE, ID-SCORES. 
ATTACH, TAPEIO, UNI TF I LE, ID-SCORES. 
LGO. 


PARENT  CALL  FILE 

CONNECT, INPUT.OUTPUT. 

ATT  ACH , LGO , P AR  ENTB IN, ID-SCORES, MR -1. 
ATTACH, TAPEH.PARENTFILE, ID-SCORES. 
ATTACH, TAPEIO.UNITFILE, ID-SCORES. 
LGO. 


FORCE  CALL  FILE 

CONNECT, INPUT,OUTPUT. 

ATTACH , LGO , FORCE8 IN , I D-SCOR  ES ,MR» 1 . 
ATTACH, TAPES, PARENTFILE, ID-SCORES. 
ATTACH, TAPE7,UNITFIL£,ID-SCC?ES. 
ATTACH, TAPE8.SRCFILE, ID-SCORES. 
ATTACH, TAP E9.F0RCEFILE, ID-SCORES. 
LGO. 


Figure  A-l.  "Call"  Files  for  the  Force  File  Generation  Process 
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A-4.  CREATION  OF  SRC  FILE.  The  SRC  file  is  intended  to  be  developed  in  a 
manner  consistent  with  the  US  Army's  concept  of  Tables  of  Organization  an.i 
Equipment  (TOE).  Each  record  consists  of  a  name  (SRC)  and  the  type  and 
quantity  of  weapons  in  the  corresponding  organization.  A  maximum  of  22 
different  types  of  weapons  can  be  entered  in  a  given  SRC.  An  example  of  a 
run  of  the  SRC  program  is  presented  in  figure  A-2.  In  this  example, 
arbitrarily  consider  itum  code  1  to  be  personnel,  item  code  2  to  be  tanks, 
and  item  code  3  to  be  APCs.  As  shown  in  figure  A-2,  the  run  is  initiated 
by  the  gamer  through  the  entry  of  the  "call"  command.  This  attaches  cycle 
1  of  two  files  (SRCF1LE  and  SRCBIN,  a  binary  file  of  the  compiled  SRC 
program)  and  executes  the  program.  Next,  as  shown  in  figure  A-2,  an  "x" 
is  entered  to  display  all  valid  action  codes.  After  this,  a  Blue  tank 
platoon  is  entered  onto  the  SRC  file  by  entering  an  "a"  action  code, 
entering  the  name  (1  to  10-character  alphanumerics)  for  the  Blue  tank 
platoon  SRC  (BTANKPLT),  and  entering  the  type  and  quantity  of  each  weapon 
in  the  Blue  tank  platoon.  In  this  instance,  20  personnel,  5  tanks,  and  1 
APC  are  entered.  Figure  A-2  also  contains  examples  of  the  other  actions 
available  to  the  gamer.  The  review  action  simply  displays  the  type  and 
quantity  of  weapons  in  a  specific  SRC.  The  change  action  allows  the  gamer 
to  modify  the  quantities  of  one  or  more  of  the  weapons  In  a  given  SRC. 

The  delete  option  removes  either  an  entire  SRC  from  the  SRC  file  or 
specific  weapons  from  a  given  SRC.  The  list  action  displays  all  the  SRCs 
with  their  weapons  on  the  SRC  file.  The  run  is  terminated  by  specifying 
an  "e"  action.  For  the  sample  run  of  other  programs,  which  follows,  the 
following  SRCs  have  been  put  onto  the  SRC  file  with  the  proper  Jiffy  Game 
item  codes: 

a.  BAHCO  -  Blue  attack  helicopter  company. 

b.  BARTYBAT  -  Blue  artillery  battery. 

c.  8ARTY8NHQ  -  81ue  artillery  battalion  headquarters. 

d.  BMECHPLT  -  Blue  mech  platoon. 

e.  BTANKPLT  -  81ue  tank  platoon. 

f.  8TANKC0HQ  -  Blue  tank  company  headquarters. 

g.  RARTYBN  -  Red  artillery  battalion. 

h.  RMECHCO  -  Red  mech  company. 

i.  RTANKBNCP  -  Red  tank  battalion  consnand  post. 

j.  RTANKCQ  -  Red  tank  company. 


A-3 


CALL , RUNSRC , ID*SCCR£S 

ENTER  ACTION  TYPE  (  X  FOR  LIST)-  X 

FOLLOWING  ACTIONS  MAY  8E  EXECUTED 
R-  READ  (REVIEW)  A  RECORD 
A*  ADD  A  NEW  SRC 

C*  CHANGE/ADD  WPN  ID'S/QTY'S  WITHIN  AN  EXISTING  SRC 
0*  DELETE  AN  SRC  AND/OR  WPN  SYS  ID  WITHIN  THE  SRC 
L»  LIST  ALL  SRC'S  ON  FILE 
E«  END  THE  PROGRAM 

ENTER  ACTION  TYP£(  X  FOR  LIST)-  A 

ADD  -  ENTER  NEW  SRC  (END  TO  EXIT)-  3TANKPLT 

ENTER  WPN  ID.QTY— 0,0  IF  DONE  1,20 

NEXT-  2,5 

NEXT-  3,1 

NEXT-  0,0  " 

AOO-ENTER  NEW  SRC  (END  TO  EXIT)—  END 


ENTER  ACTION  TYPE(  X  FOR  LIST)-  R 

READ-ENTER  SRC(ENO  TO  EXIT)-  BTANKPLT 

SRC3BTANKPLT  id  qty 

1  20. 

2  5. 

3  1.  • 

READ-ENTER  <:RC  (END  TO  EXIT)-  END 


Figure  A-2.  Sample  Run  of  SRC  Program. 
(Continued  next  page.) 
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ENTER  ACTION  TYP£(  X  FOR  LIST)- 

CHANGE-ENTER  SF.C(ENO  TO  EXIT)-  3TANKPLT 

ENTER  TOTAL  NO.  OF  WPR  SYS  IDS 
I 

ENTER  WPN  I'D,QTY,ID,QTY. — 

1,23 

CHANGE-ENTER  SRC(ENO  TO  EXIT)-  END 

ENTER  ACTION  TYPE(  X  FOR  LIST)-  L 

SRC*  BTANKPLT  ID  QTY 

1  23. 

2  5. 

3  1. 


ENTER  ACTION  TYPE(  X  FOR  LIST)-  D 

DELETE-ENTER  SRC(ENO  TO  EXIT)-  BTANKPLT 

ENTER  TOTAL  NO.  OF  WPN  SYSTEMS  TO  BE  DELETED-ENTER  0  IF  ALL 

DELETE-ENTER  SRC(ENO  TO  EXIT)--  END 

ENTER  ACTION  TYPE(  X  FOR  LIST)-  R 

READ-ENTER  SRC  (END  TO  EXIT)-  *•  BTANKPLT 

SRC  BTANKPLT  NOT  ON  FILE 

READ-ENTER  SRC( END  TO  EXIT)—  END 

ENTER  ACTION  TYPE(  X  FOR  LIST)-  E  ' 


ANY  MORE  FORCE  STRUCTURES  TO  BE  UPDATED? 

N 

ALL  DONE  JOB  HAS  ENOED 
STOP 

Figure  A-2.  Sample  Run  of  SRC  Program  (concluded) 


A-5.  UNIT  FILE  CREATION.  Once  the  gamer  has  specified  all  the  SRCs 
necessary  to  initialize  the  scenario,  a  file  of  the  combat  units  may  be 
built.  This  is  accomplished  through  the  execution  of  the  UNIT  program.  A 
sample  run  of  the  UNIT  program  is  presented  in  figure  A-3.  As  can  be  seen 
from  the  sample  run,  the  process  to  build  units  from  SRCs  is  similar  to 
that  of  the  SRC  program.  Again,  the  gamer  initiates  the  run  through  the 
interactive  "call"  command,  which  attaches  three  files  (SRCFILE,  UNITFILE, 
and  UNITBIN,  the  UNIT  program  compiled  binary  file)  and  executes  the 
program.  The  "x"  action  code  entry,  as  before,  displays  the  valid  action 
codes  available  to  the  gamer.  The  sample  run  demonstrates  the  addition  of 
two  units  to  the  UNIT  file:  a  Blue  armor  company  team  consisting  of  two 
tank  platoons,  a  mech  platoon,  and  a  tank  company  headquarters ;  and  a 
reinforced  Red  tank  battalion  consisting  of  three  tank  companies,  a 
mechanized  rifle  company,  and  a  tank  battalion  command  post.  The  other 
actions  of  the  UNIT  program  are  virtually  identical  to  those  of  the  SRC 
program  exemplified  in  figure  A-2.  A  listing  of  all  units  on  the  UNITFILE 
(action  type  1)  has  been  included  in  figure  A-3. 
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CALL, RUNUNIT, ID-SCORES 

ENTER  ACTION  TYPE(  X  FOR  LIST) — 

FOLLOWING  ACTIONS  CAN  BE  EXECUTED 
R»R£AO (REVIEW)  A  RECORD 
A-ADD  A  NEW  UNIT 

C«ADO  SRC'S  WITHIN  AN  EXISTING  FORCE 
Q-OELETE  A  UNIT  ANO/OR  SRC'S  WITHIN  THE  UNIT 
L-LIST  ALL  UNITS  ON  FILE 
E*ENG  THE  PROGRAM 

ENTER  ACTION  TYPE(  X  FOR  LIST)-  A 

ADO-ENTER  NEW  UNIT  IO(£ND  TO  EXIT)— BA/1-1A 

ENTER  SCR(0  IF  OONE)-  BTANXPLT 

NEXT-  BTANKPLT 

NEXT-  BMECHPLT 

NEXT-  BTANKCOHQ 

NEXT-  0 

ADO-ENTER  NEW  UNIT  IO(ENO  TO  EXIT)-  R5-6A 

ENTER  SRC  (0  IF  DONE)-  RTANKCO 

NEXT-  RTANKCO 

NEXT-  RTANKCO 

NEXT-  RMECHCO 

NEXT-  RTANK8NCP 

NEXT-  0 

ADO-ENTER  NEW  UNIT  IO(ENO  TO  EXIT)— END 

Figure  A-3.  Sample  Run  of  UNIT  yroarm  (continued) 
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ENTER  ACTION  TYPE(  X  FOR  LIST)-  '  L 


UNIT-B3-11FA 

BARTYBAT 

BARTYBAT 

3ARTYBAT 

UNIT-B7AVNC0 

SRC 

BANCO 

UNIT-BA/1-1A 

SRC 

BTANKPLT  ' 
BTANKPLT 
BMECHPLT 
8TANKC0HQ 

UNIT*8B/1-1A 

SRC 

BTANKPLT 

BTANKPLT 

BMECHPLT 

BTANKCOHQ 

UNIT*BC/1-1A 

BTANKPLT 

BTANKPLT 

BMECHPLT 

BTANKCOHQ 

UNIT-R1-2FA 

SRC 

RARYTBN 

UNIT-R2-2FA 

SRC 

RARYTBN 

UNIT*R3-2FA 

tor 

RARYT3N 

UNIT-R5-6A 

SRC 

RTANKCO 

RTANKCO 

RTANKCO 

RMECHCO 

RTANKBNCP 

UNIT*R6-6A 

SRC 

RTANKCO 

■ 

RTANKCO 

RMECHCO 

RMECHCO 

RTANKBNCP 

UNIT-R7-6A 

SRC 

RTANKCO 

RTANKCO 

RTANKCO 

RTANKCO 

RTANKBNCP 

Figure  A-3.  Sample  Run  of  UNIT  Program  (continued) 


ENTER  ACTION  TYP£(  X  FOR  LIST)-  E 

ANY  MORE  FORCE  STRUCTURES  TO  BE  UPDATED? 
N 

ALL  DONE  J03  HAS  ENDED 
STOP 


Figure  A-3.  Sample  Run  of  UNIT  Program  (concluded) 


A-6.  PARENT  UNIT  FILE  CREATION.  The  PARENTFILE  is  a  file  on  which  the 
units  defined  on  the  UNIFILE  are  grouped,  if  desired,  into  higher  echelon 
organizations.  A  'ample  run  of  the  PARENT  program  is  given  in  figure 
A-4.  As  before,  ?  :e  "call"  command  is  entered  to  attach  the  UNITFILE, 
PARENTFILE,  AND  Pr>ENT3IN  (the  binary  compiled  file  of  the  PARENT  program) 
and  to  execute  the  program.  An  "x*  action  type  entry  displays  the  valid  . 
action  codes.  The  sample  run  demonstrates  the  entries  of  two  common 
variations  of  parent  unit  groupings.  The  first  parent  unit  entered  was 
for  B1-1A.  In  this  example,  the  parent  unit,  a  battalion,  is  composed  of 
the  companies:  BA/1-1A,  BB/1-1A,  and  BC/1-1A.  The  second  example  is  for 
B7AVN,  which  has  only  one  subordinate  unit  in  it.  A  "1“  action  listing  of 
the  parent  unit  organizations  is  also  provided  in  figure  A-4.  As  in  the 
UNIT  program,  the  other  valid  action  types  are  similar  to  those  of  the  SRC 
program,  and  example  runs  may  be  found  in  figure  A-2. 


CALL.RUNPARENT,  ID-SCORES 

ENTER  ACTION  TYP£(  X  FOR  LIST)-  X  • 

FOLLOWING  ACTIONS  CAN  8E  EXECUTED 
R*READ  (REVIEW  A  RECORD) 

A*AOD  A  NEW  FORCE 

C*ADO  UNIT'S  WITHIN  AN  EXISTING  FORCE 
D-OELETE  A  FORCE  ANO/OR  UNITS  WITHIN  THE  FORCE 
L-LIST  ALL  FORCES  ON  FILE 
£«ENO  THE  PROGRAM 

ENTER  ACTION  TYP£(  X  FOR  LIST)—  A 

ADD-ENTER  NEW  FORCE  ID(ENO  TO  EXIT) — 81  1A 
ENTER  UNIT  (0  IF  DONE)-  BA/1-1A 
NEXT-  BB/1-1A 
NEXT-  BC/1-1A 
NEXT-  0 

ADD-ENTER  NEW  FORCE  ID(£N0  TO  EXIT)~B7AVN 
ENTER  UNIT(0  IF  DONE)-  B7AVNC0 
NEXT-  0 

ADO-ENTER  NEW  FORCE  ID  (END  TO  EXIT)— END 


Figure  A-4.  Sample  Run  of  PARENT  Program  (continued) 
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ENTER  ACTION  TYP£(  X  FOR  LIST)-  L 


F0RCE-81-1A 

UNIT 

BA/1-1A 

B8/1-1A 

BC/1-1A 

F0RCE*B3-11FA 

UNIT 

83-11FA 

FORCE-B7AVN 

UNIT 

B7AVNC0 

FORCE*R2FA 

UNIT 

R1-2FA 

R2-2FA 

R3-2FA 

F0RCE*R6A 

UNIT 

R5-6A 

R6-6A 

R7-6A 

ENTER  ACTION  TYPE(  X  FOR  LIST)-  E 

ANY  MORE  FORCE  STRUCTURES  TO  BE  UPDATED?. 

N 

ALL  DONE  JOB  HAS  ENOED 
STOP 


Figure  A-4.  Sample  Run  of  PARENT  Program  (concluded) 
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A-7.  FORCE  FILE  CREATION.  The  FORCEFILE  is  actually  a  consolidation  of 
the  Information  contained  on  the  other  three  files  in  a  format  suitable 
for  processing  in  the  Jiffy  Game.  A  sample  run  of  the  FORCE  program  Is 
presented  in  figure  A-5.  The  interactive  "call"  command,  which  for  the 
FORCE  program  attaches  five  files  (SRCFILE,  UNITFILE,  PARENTFILE, 
FORCEFILE,  and  FORCEBIN,  the  force  program  compiled  binary  file)  and 
executes  the  program,  is  preceded  by  an  attach  of  the  Jiffy  Game  random 
access  data  base,  which  is  the  unclassified  version  for  this  example.  The 
first  entry  In  the  FORCE  program  identifies  the  force  into  which  the 
parent  units  are  to  be  initialized.  The  force  entry  must  be  either  "b", 
denoting  the  Blue  force,  or  “r“  denoting  the  Red  force.  After  the  force 
type  specification,  the  valid,  actions  are  displayed  with  an  "x"  action 
entry.  Next,  since  a  "b"  was  entered  for  force  type,  all  parent  units 
entered  are  for  81ue.  Following  the  entry  of  each  parent  unit,  the  user 
assigns  a  unit  effectiveness,  a  combat  Intensity  level,  and  an  EW  type  to 
every  subordinate  unit  within  the  designated  parent.  Normally  the  unit 
effectiveness  entry  Is  100;  however,  if  a  game  is  being  started  with  the 
asSunptlon  that  some  previous  attrition  has  taken  place,  then  the  unit 
effectiveness  may  be  less.  The  EW  types  are  given  in  Figure  B-5.  This 
procedure  Initializes  the  units  onto  the  FORCEFILE.  Note  that  during  this 
process,  the  computer  displayed  some  extraneous  information  in  the  sample 
run  after  the  relative  (unit)  effectiveness  specifications  for  BC/1-1A  and 
BS-11FA.  This  information  is  displayed  each  time  one  of  the 
Indexed- sequential  files  is  automatically  extended  by  the  computer’s 
operating  system.  After  the  initialization  of  the  Blue  force  onto  the 
FORCEFILE,  a  "1"  option  Is  entered  to  display  all  the  units  and  parent 
units  with  their  associated  weapon  systems.  As  shown  in  the  display  in 
figure  A-5,  all  the  units  are  in  sector  0  of  an  undefined  critical 
Incident.  These  game  variables  are  set  during  the  actual  processing  of 
the  Jiffy  Game.  The  "1"  action  automatically  ends  the  Blue  (or  Red) 
session  of  the  FORCE  program  and  returns  it  to  the  point  in  the  program 
that  defines  the  type  force;  otherwise,  the  session  is  ended  with  the  "e“ 
action.  The  Red  session  Is  Initiated  with  an  "r"  force  specification. 

The  Red  units  are  defined  and  listed  the  same  as  the  Blue  forces.  The 
FORCE  program  is  terminated  through  the  specification  of  an  "e"  action. 


ATTACH , CLD ATA , UNDATA  *  I D -SCORES 

CALL,  RUNFQRCE, ID-SCORES 

IDENTIFY  TYPE  FORCE-.-  B 

ENTER  ACTION  TYPE  (  X  FOR  LIST)-  X 

FOLLOWING  ACTIONS  MAY  BE  EXECUTED 
A*  ADO  NEW  FORCES 

C»  CHANGE  A  UNIT'S  EFFECTIVENESS,  CIL,  OR  UNIT  TYPE 
D«  DELETE  A  FORCE(PARENT  UNIT) 

R*  REAO  (REVIEW)  PARENTS 
L«  LIST  ALL  PARENTS 
E»  ENO  THE  PROGRAM 

ENTER  ACTION  TYPE  (  X  FOR  LIST)-  A 

ENTER  MAJOR  FORCE  (0  IF  DONE)-  Bl-IA 

ENTER  REL  EFF.CBT  INTENSITY,  LVL,  AND  UNIT  TYPE  OF  BA/1-1A  100,4,4 

ENTER  REL  EFF.CBT  INTENSITY  LVL,  AND  UNIT  TYPE  OF  8A/1-1A  100,4,4 

ENTER  REL  EFF.CBT  INTENSITY  LVL,  AND  UNIT  TYPE  OF  BA/1-1A  100,4,4 

NEXT-  83-11FA 

ENTER  REL  EFF.CBT  INTENSITY  LVL,  AND  UNIT  TYPE  OF  B3-11FA  100,1,3 

NEXT-  B7  AVN 

ENTER  REL  EFF.CBT  INTENSITY  LVL,  AND  UNIT  TYPE  OF  B7AVNC0  100,1,2 

NEXT-0 

ENTER  ACTION  TYPE  (  X  FOR  LIST)-  L 

FORCE-  B 
FORCE  ID3  81-1A 

UNIT  10:  BA/l-lA  ;  LAST  Cl;  SECTOR:  0. 

WPN 

ID  QTY 


2 

79 

3 

30 

il 

10 

16 

12 

25 

5 

26 

3 

Figure  A-5.  Sample  Run  of  FORCE  Program  (continued  next  page) 
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EFFECTIVENESS  OF  BA/1-1A  *  100. 

UNIT  10:  BB/1-1A  ;  LAST  Cl:  SECTOR:  0. 

WPN 

ID  QTY 

2  79. 

3  30. 

11  10. 

16  12. 

25  5. 

26  3  • 

EFFECTIVENESS  OF  B8/1-1A  *  100. 

UNIT  ID:  BC/1-1A  ;  LAST  Cl:  SECTOR:  0. 

WPN 

ID  QTY 

2  79. 

3  30. 

11  10. 

16  12. 

25  5. 

26  3. 

EFFECTIVENESS  OF  BC/1-1A  -  100. 

AVERAGE  EFFECTIVENESS  OF  B1-1A  *  100. 

FORCE  ID*  B3-11FA 

UNIT  ID:  83-11FA  ;  LAST  Cl:  SECTOR:  0. 

WPN 

ID  QTY 

2  180. 

50  18. 

EFFECTIVENESS  OF  B3-11FA  *  100. 

AVERAGE  EFFECTIVENESS  OF  B3-11FA  -  100. 

FORCE  ID*  B7AVN 

UNtlT  ID:.  87AVNC0  ;  LAST  Cl:  SECTOR:  0. 

WPN 

ID  QTY 

'  2  40. 

62  15. 

63  ,5. 

EFFECTIVENESS  OF  B7ANVC0  »  90. 

AVERAGE  EFFECTIVENESS  OF  B7ANVC0  *  90. 

IDENTIC  TYPE  FORCE-  R 

ENTER  ACTION  TYP£{  X  FOR  LIST)—  A 
ENTER  MAJOR  FORCES  (0  IF  DONE)  -  R2FA 


Figure  A-5.  Sample  Run  of  FORCE  Program  (continued) 


ENTER  REL  EFF,  C8T  INTENSITY  LVL,  ANO  UNIT  TYPE  OF  R1-2FA 

ENTER  REL  EFF,  C8T  INTENSITY  LVl,  AND  UNIT  TYPE  OF  R2-1FA 

ENTER  REL  EFF,  C3T  INTENSITY  LVL,  AND  UNIT  TYPE  OF  R3-2FA 

NEXT-  R6A 

ENTER  REL  EFF,  C8T  INTENSITY  LVL,  AND  UNIT  TYPE  OF  R5-6A 

ENTER  REL  EFF,  C8T  INTENSITY  LVL,  AND  UNIT  TYPE  OF  R6-6A 


ENTER  REL  EFF,  C3T  INTENSITY  LVL,  AND  UNIT  TYPE  OF  R7-6A 
NEXT-  0 


ENTER  ACTION  TYP£(  X  FOR  LIST)  — 

TYPE  FORCE*  R 

FORCE  ID-  R2FA 

L 

UNIT  ID:  R1-2FA  ; 

LAST  Cl: 
WPN 

ID 

QTY 

1 

21. 

2 

211. 

25 

3. 

48 

17. 

EFFECTIVENESS  OF  R1-2FA 

-  95. 

UNIT  ID:  R2-2FA  ; 

LAST  Cl: 

‘ 

WPN 

ID 

QTY 

1 

20. 

2 

202. 

25 

3. 

48 

16. 

EFFECTIVENESS  OF  R2-2FA 

-  91. 

UNIT  ID:  R3-2FA  ; 

LAST  Cl: 

WPN 

ID 

QTY 

. 

1 

21. 

2 

215. 

25 

3. 

48 

17. 

EFFECTIVENESS  OF  R3-2FA 

*  97. 

AVERAGE  EFFECTIVENESS  OF  R2FA  . 

»  94; 

SECTOR:  0. 


SECTOR:  0. 


SECTOR:  0. 


100,1,3 

100,1,3 

100.1.3 

100.4.4 
100,4,4 
100,4,4 


Figure  A-5.  Sample  Run  of  FORCE  Program  (continued) 
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.  APPENDIX  B 

SAMPLE  RUN  OF  THE  JIFFY  GAME 
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SAMPLE  RUN  OF  THE  JIFFY  GAME 


B-l.  PURPOSE  AND  SCOPE.  The  purpose  of  this  appendix  is  to  provide  the 
user  a  step  by  step  procedure  for  playing  the  interactive  Jiffy  Game. 

8-2.  GENERAL.  The  computer  performs,  basically,  two  major  tasks  in  the 
“Jiffy"  war  gaming  process.  First,  it  is  used  for  bookkeeping  in  the 
sense  that  it  keeps  track  of  the  units  being  gamed  and  updates  their' 
status  for  attrition  suffered  in  combat  and  other  changes  to  their  status, 
which  may  be  entered  manually.  Second,  the  computer  is  used  to  perform 
the  attrition  calculations  and  keep  a  .record  of  vital  combat  statistics. 

8-3.  INITIATION  OF  THE  GAME.  After  all  the  units  to  be  entered  into 
combat  have  been  initialized  on  the  FORCEFILE  (see  appendix  A),  and  an 
empty  history  file  (HISTORYFILE)  has  been  created,  the  user  is  ready  to 
begin  processing  the  Jiffy  Game.  Figure  3-1  contains  a  call  file  pair. 

The  first  attaches  and  processes  the  proper  files  to  execute  the  game. 

The  second  call  file  preserves  the  user’s  answers  in  forms  convenient  for 
regaming.  Before  the  “call"  file  is  entered  by  the  user,  however,  the 
data  file  (CLDATA)  must  be  attached.  Figure  3-2  contains  an  example  of 
♦Ms  process  and  the  initial  user  responses  necessary  to  process  the 
game.  In  figure  3-2,  the  user  is  asked  to  specify  the  purpose  of  the 
run.  The  entry  of  999  reveals  that  this  user  response  selects  the  mode 
(interactive,  batch,  or  interactive  answer  file  making)  under  which  the 
game  Is  to  be  run.  Generally  a  "4“  is  entered  here.  Next  the  program 
come  to  the  decision  point.  The  entry  of  999  displays  all  the  alternative 
courses  of  action  available  to  the  user  at  this  point  as  depicted  In 
figure  B-2. 


CONNECT, INPUT.TAPE50. 

REQUEST, STATS, *PF.  - 

AUDIT, IO*SCGRES,AI»S,LF»STATS,PF«E30ATA. 

ATTACH, JIFFY, E3BINSEG, ID-SCORFS.MR-l . 

ATTACH,TAPE9,SRCFIL£,ID»SCCRES. 

ATTACH,TAPE55,F0RCEFIL£,ID»SCQRES. 

ATTACH,TAPE3,HIST0RYFILE,ID*SCCRES. 

ATTACH, SEG, SEGMENT,  ID-XJIFFYM, MR  =»1. 

attach,review,id»scqres. 

$EGLOAO,I»SEG. 

JIFFY. 

CALl,ANS,IQ»XJIFFYM. 


ATTACH .OLD ,RAN$WER , ID»EUR III. 

COPYCF  ,010 , RANSWER , 999 . 

BKSP, RANSWER. 

REWIND, ANSWER. 

COPYCF, ANSWER, RANSWER. 

££^°1’RANSW£R .RANSWER .  IO-EURI 1 1  ,MR«1. 
PURGE, PI,RANSWER,ID.EURIII,LC«l. 

CATALOG tQA,RREVI£W,IO»EURII I. 
PURGE,PREV,RREVI£W,ID*EURIII,LC»1. 


Figure  3*1.  Call  File s  to  Run  the  Main  Jiffy  Program 
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aumm  w.:. 


CALL, DO GAME, ID*XJIFFYM 


CACOA  JIFFY  WAR  GAME 

SPECIFY  PURPOSE  OF  THIS  RUN999 

ENTER  1  *  TO  CREATE  INPUT  FILE  OF  ANSWERS  FOR  BATCH  JOB 
ENTER  2  »  TO  GET  OUTPUT  OF  RESULTS  INTERACTIVELY 
ENTER  4  ■  TO  GET  TERMINAL  OUTPUT  AND  MAXE  ANSWER  FILE 
SPECIFY  PURPOSE  OF  THIS  RUN— 4 


???  DECISION  POINT  ???999 

ENTER  1  TO  LOAD  FORCES  INTO  A  SECTOR 

2  TO  CALCULATE  RATE-OF-AQVANCE 

3  TO  ASSESS  C0M8AT 

4  TO  APPORTION  CBT  LOSSES  TO  UNITS 

5  TO  DISPLAY  BATTLE  STATISTICS 

6  TO  DISPLAY  WEAPON  ARRAYS 

7  TO  ADD  SRC’S  TO  TOE  FILE 

8  TO  RESTART  AT  A  PREVIOUSLY  GAMED  Cl 

9  TO  END  GAME  AND/OR  UPOATE  HISTORY  FILE 
10  TO  RESET  ELEMENT  ARRAY  FROM  INPUT  FILE 
12  TO  RESET  TERMINAL  OUTPUT  FILE 


(Decision  point  11  was  "to  review  previous  run."  This  can  now  be  done  at 
any  Interactive  point  hy  entering  “9998".  See  4e(2)  for  further 
discussion.) 


Figure  B-2.  Initiation  of  Sampie  Jiffy  Game  Run. 


8-4.  FORCEFILE  MANIPULATION.  The  units  involved  in  the  combat  to  be 
gamed  must  be  loaded  into  their  respective  sectors  before  any  Jiffy  Game 
assessments  can  be  processed.  The  units  on  the  FORCEFILE  are  loaded  into 
sectors  by  the  procedures  available  to  the  user  through  DECISION  POINT  1. 
Figure  3-3'  contains  examples  of.  these  file  manipulation  options.  After 
entering  a  "1"  at  the  DECISION  POINT,  the  user  is  asked  to  input  the 
critical  incident  mnemonic  identifier  (1  to  10  alphanuneric.  characters) 
and  the  sector  number  to  be  gamed.  In  the  example,  these  are  entered  as 
"TEST"  and  "1"  respectively.  As  seen  In  figure  8-3  a  999  entered  at 
OPTION  displays  the  force  file  manipulation  options  available  to  the  user. 

a.  An  example  of  the  option  that  enables  the  user  to  create  units 
during  the  game  is  also  included  in  the  sample  run.  The  create  option, 
OPTION  3,  provides  two  ways  of  creating  units.  First,  the  user  Is  allowed 
to  use  SRCs,  which  exist  on  the  SRCFILE,  to  define  the.  subuni* 
organizations  of  the  unit  being  created.  An  example  of  this  procedure  has 
not  been  Included  in  the  sample  run,  because  it  is  similar  to  the 
procedures  presented  in  appendix  A.  Second,  the  user  is  allowed  to  create 
a  unit  through  the  specification  of  the  types  and  quantities  of  weapon 
systems  contained  in  the  unit.  An  example  of  this  type  of  create  is 
Included  in  figure  3-3. 

b.  Option  1  allows  the  user  to  load  units  Into  the  current  sector 
during  the  game.  In  figure  3-3  the  unit  test  created  is  entered  into  the 
current  sector. 

c.  An  example  of  the  display  option  Is  next  given.  Units  11  and  12 
are  displayed. 

d.  Next  an  example  of  option  8  Is  shown.  Units  11  and  12  are. 
combined.  After  this  the  display  option  is  used  to  look  at  the  new  unit 
11. 

e.  An  example  of  OPTION  2,  the  remove  option.  Is  presented.  This 
option  allows  the  user  to  remove  a  unit  from  a  sector  into  which  it  was 
loaded.  When  a  unit  is  removed  from  a  sector,  1,t  Is  loaded  Into  sector  0 
of  the  specific  critical  incident. 

f.  An  example  of  OPTION.  4,  the  option  that  provides  the  user  the 
capability  to  adjust  (add  or  subtract)  weapons  systems  in  a  unit.  Is  also 
presented,  which  changes  the  quantity  of  weapon  type  2  in  unit  3  A/1-23A., 

g.  The  options  of  DECISION  POINT  1  are  always  concluded  with  the 
specification  of  OPTION  0.  This  option  fills  the  weapon  system  arrays, 
which  are  used  in  the  Jiffy  Game  assessment  routines,  with  the  weapons  of 
the  units  that  have  been  loaded  into  the  sector  and  critical  incident 
being  gamed. 


8-4 


???  0  £  C  I  S  I  0  N  P  0  I  N  T  ??? 

1 

ENTER  Cl  MNEMONIC  - 
TEST 

ENTER  SECTOR  NUMBER  - 

1 

SECTOR  1.  WAS  PREVIOUSLY  GAMED. 

IS  THIS  SECTOR  BEING  REGAMED  NOW? 

Y 

ALL  STATS  RECORDS  FOR  SECTOR  1.  CF  Cl  TEST  HAVE  BEEN 

ZEROED  OUT  ON  HISTORYFILE. 

???  0  P  T  I  0  N  ??.' 

999 

ENTER  0  TO  PPOCEDE  WITH  ASSESSEMENTS 
'  1  TO  LOAD  UNITS  INTO  SECTOR 

2  TO  REMOVE  UNITS  FROM  SECTOR 

3  TO  CREATE  A  NEW  UNIT 

4  TO  .ADJUST  WPNS  IN  A  UNIT 

5  TO  ATTACH  A  UNIT  TO  A  NEW  PARENT 

6  TO  DISPLAY  A  UNIT 

7  TO  DELETE  A  UNIT  FROM  FORCE  FILE 

8  TO  COMBINE  UNITS 

???  0  P  T  I  0  N  ??? 

3 

ARE  THERE  ANY  BLUE  UNITS  TO  CREATE? 

Y 

ENTER  PARENT  UNIT  ID  - 
1 

ENTER  UNIT  ID  - 
11 

CREATE  BY  SRC’S? 

N 

ENTER  WPN  ID,qTY~0,0  WHEN  DONE 

32.10 
NEXT- 

36.10 
NEXt- 

39.10 
NEXT- 

0,0  " 

ENTER  RELATIVE  EFFECTIVENESS- 
100 

CREATE  ANOTHER  UNIT  FOR  THIS  FORCE? 

N 


Figure  3-3.  FORCEFILE  Manipulation  .'continued). 


8-5 


1 

ENTER  PARENT  OF  UNIT(S)  TO  BE  LOADED  INTO  SECTOR- 

ENTER  UNIT  ID  (OR  ALL)- 
ALl 

LOAD  ANOTHER  UNIT? 

N 

???  0  P  T  I  0  N  ???6 
ENTER  TYPE  OF  DISPLAY  -999 
ENTER  1  TO  DISPLAY  ALL  PARENT  UNITS  IN  FORCEFILE 
2  TO  DISPLAY  ALL  PARENT  UNITS  IN  SECTOR 
.3  TO  01 SPLAY  UNITS  IN  A  SPECIFIC  PARENT  ' 
4  TO  DISPLAY  WEAPONS  IN  A  UNIT 
ENTER  TYPE  OF  DISPLAY  -4 
ENTER  PARENT  OF  UNIT(S)  TO  BE  DISPLAYED  -1 
ENTER  UNIT  ID  (OR  ALL)  -11 


1  EFF-100. 


11 

EFF-100. 

ITEM  CODE 

32  36 

39 

#  REMAIN 

10.0  10.0 

10.0 

#  LOST 

Q.C  .0*0 

0.0 

ANOTHER  01  SPLAY?  Y 

ENTER  TYPE  OF  DISPLAY  -4 

ENTER  PARENT  OF  UNITS(S)  TO  8E  DISPLAYED  -1 

ENTER  UNIT  ID  (OR  ALL)  -12 

1  EFF-100. 


12  EFF-100. 


ITEM  CODE  61  62 

#  REMAIN  10.0  10.0 

#  LOST  0.0  0.0 

ANOTHER*  DISPLAY?* . *N . . 

???  0  P  T  I  0  N  ???8 
PARENT  ID  OF  HOST  »  i 
UNIT  10  -  11 

PARENT  ID  OF  DISBANDING  UNIT  •  1 

UNIT  ID  «  12 

Figure  B-3.  FORCEFILE  Manipulation  (continued) 
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77?  0  P  T  I  0  N  7776 

ENTER  TYPE  OF  DISPLAY  -4 

ENTER  PARENT  OF  UNIT(S)  TO  BE  DISPLAYED  -1 

ENTER  UNIT  ID  (OR  ALL)  -11 


1  EFF-272 


11 

EFF*272 

ITEM  CODE 

32 

36 

39  61 

62 

#  REMAIN 

10.0 

10.0 

10.0  10.0 

10.0 

#  LOST 

0.0 

0.0 

0.0  0.0 

0.0 

ANOTHER  DISPLAY7N 


???  0  P  T  I  OK  777  2 

PARENT  OF  UNIT(S)  TO  BE  REMOVED-  Bl-lA 

ENTER  UNIT  ID  (OR  ALL)-  BC/1-1A 

REMOVE  ANOTHER  UNIT?  N 

77?  OPTION  77?  4 

ENTER  PARENT  OF  UNIT  TO  BE  AOJUSTEO  -8A/1-23A 

ENTER  UNIT  ID-  BA/1-23A 

ENTER  WPN  ID, NEW  QTY-0,0  WHEN  OONE  2,23 

(The  "New  Qty",  23,  Is  an  Incremental  value,  that  Is,  23  Items  coded  2 
have  been  added  to  whatever  Is  there.  It  can  also  be  negative.) 

NEXT-  0,0 

ANY  MORE  UNITS  TO  CHANGE?  N 


Figure  B-3.  FORCEFILE  Manipulation  (continued) 


???  0  P 


T  I  0  N  ???  0 

DO  YOU  WISH  TO  SEE  UNITS  LOADED  INTO  SECTOR? 
Y 


UNITS 

LOADED  INTO 

SECTOR 

1. 

FOR  Cl 

TEST 

FORCE. 

PARENT 

UNIT 

TYPE 

CIL 

EFF 

1 

1 

11 

1 

5 

100 

1 

1 

12 

2 

5 

100 

1 

1 

13 

3 

5 

100 

1 

1 

14 

4 

5 

100 

2 

2 

21 

1 

5 

100 

2 

2 

22 

2 

5 

100 

2 

2 

23 

3 

5 

100 

2 

2 

24 

4 

5 

100 

Figure  B-3.  FORCEFILE  Manipulation  (concluded) 
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8-5.  RATE  OF  ADVANCE.  After  all  units  for  each  force  have  been  loaded 
Into  a  sector,  the  rate  of  advance  and,  subsequently,  the  combat 
assessments  for  that  sector  can  be  processed.  It  should  be  noted  here 
that  neither  rate  of  advance  nor  combat  assessments  need  be  done 
inmediately  after  the  units  have  been  loaded  in  a  sector.  Most  users  of  . 
the  Jiffy  Game  to  data  have  found  that  It  is  more  efficient  to  load  the 
units  Into  all  sectors  for  a  particular  critical  incident  (Cl)  prior  to 
running  any  rate  of  advance  or  assessment  routines. 

a.  The  example  given  In  figure  8-3  demonstrated  the  loading  of  units 
Into  sector  1  of  a  Cl  identified  as  TEST.  The  weapon  system  array  created 
by  selecting  OPTION  0  (zero)  is  displayed  by  entering  a  "6"  at  DECISION 
POINT  as  shown  in  figure  B-4.  This  array  is  used  in  the  rate  of  advance 
calculations;  the  FORCEFILE  Itself  Is  not  operated  on  during  this  portion 
of  the  Jiffy  Game. 

b.  Figure  8-5  Is  a  sample  run  of  the  rate  of  advance  routine,  which 
is  Initiated  by  entering  a  “2"  at  DECISION  POINT.  Where  app»*jpriate,  a 
999  has  been  entered  to  display  the  Input  options  available  o  the  user. 
The  responses  given  In  this  example  are  not  intended  to  portray 
realistically  any  particular  battlefield  situation  but  have  been  selected 
in  such  a  way  that  all  posslbile  inputs  that  might  be  required  are  shown. 
Input  of  an  attacker  posture,  for  example,  is  not  asked  for  whenever. a  "1" 
(meeting  engagement),  a  "2”  (delay),  or  a  "3"  (withdraw)  is  entered  for 
the  type  of  engagement.  Some  Inputs  in  rate  of  advance  set  parameters 
that  determine  Input  requirements  or  limitations  In  the  combat  assessment 
portion  of  the  game.  The  minefield  employment  response  given  in  this 
routine,  for  Instance,  determines  whether  or  not  minefield  assessments 
can  be  made.  The  Inputs  made  In  this  routine  serve  primarily  to  represent 
the  environmental  and  military  conditions  of  the  battlefield.  The  meaning 
and  significance  of  these  parameters  to  the  Jiffy  Game  methodology  are 
documented  in  the  Jiffy  Game  Technical  Manual  (reference  2).  Not 
demonstrated. In  the  sample  run  is  the  result  of  entering  the  rate  of 
advance  routine  when  the  defending  force  has  no  weapons  in  the  array. 
Should  this  occur,  an  error  message  Is  displayed  just  after  the  Blue  air 
threat  input  is  made,  and  the  program  returns  imnediately  to  the  DECISION 
POINT  during  an  interactive  run.  (In  a  batch  processing  mode,  execution 
of  the  program  is  terminated.) 


Figure  B- 


???  D  E  C  I  S  I  0  N  POINT??? 
6 

FORCE  STRUCTURES 


ELEMENT 

BLUE 

REO 

1 

100. 

100 

2 

100. 

ICO 

3 

100. 

100 

5 

100. 

100 

5 

100. 

100 

11 

10. 

10 

13 

10. 

10 

16 

10. 

10 

21 

10. 

10 

29 

10. 

10 

31 

0. 

10 

32 

10. 

0 

36 

10. 

0 

37 

0. 

10 

39 

10. 

10 

43 

10. 

10 

46 

10. 

10 

50 

10. 

10 

61 

.  10. 

0 

62 

10. 

10 

63 

0. 

10 

.  Initial  Weapon  System  Array  for  Sample  Runs. 
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???  0  E  C  I  S  I  0  N  POINT??? 

2 

IS  BLUE  ATTACKING  RED? 

N 

ENTER  TYPE  OF  ENGAGEMENT 
999 

FOR  MEETING  ENGAGEMENT . ENTER  1 

DELAY . ENTER  2 

WITHORAW . ENTER  3 

DEFEND  FORTIFIED  POSITION . ENTER  4 

DEFEND  PREPARED  POSITION . .....ENTER  5  . 

DEFEND  HASTY  POSITION . ENTER  5 

ENTER  TYPE  OF  ENGAGEMENT 
5 

ENTER  ATTACKER  POSTURE 
999 

FOR  FRONTAL  ATTACK . ...ENTER  1 

SINGLE  ENVELOPMENT . ENTER  2 

OOUBLE  ENVELOPMENT . ENTER  3 

ENTER  ATTACKER  POSTURE 
2 

ENTER  THE  BLUE  FIREPOWER  SCORE  (0  OR  MORE)  FOR  TACAIR 
0 

ENTER  THE  RED  FIREPOWER  SCORE  (0  OR  MORE)  FOR  TACAIR 
0 

PLAY  EW? 

V 

ENTER  EW  SEED- 
TOMATO 

ENTER  THE  #  OF  RED  EW  MISSIONS  REQUESTED  (MAX*50) 

20 

CHANGE  EW  PRIORITY? 

Y 

THE  PRESENT  ORDER  OF  PRIORITY  IS: 

1  AIR  OEFENSE  ARTILLERY 

2  ATTACK, HELICOPTERS 

3  ARTILLERY  UNITS 

4  MANEUVER  UNITS 

ENTER  THE  4  ITEM  NUMBERS  FROM  HIGH  TO  LOW  PRIORITY 
3, 1*2, 4 

CHANCE  ROLL  WAS  6 
CHANCE  ROLL  WAS  5 
CHANCE  ROLL  WAS  3 
CHANCE  ROLL  WAS  5 


Figure  B-5.  Rate  of  Advance  (continued) 
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PERCENT  BLUEADA  FP  SCORE  DEGRADED-  .99 
PERCENT  BLUEAH  FP  SCORE  DEGRADED-  .10 
PERCENT  8LUEARTY  FPS  &  MISSIONS  OEGRADED-  .60 
PERCENT  BtUEMNR  FP  SCORE  OEGRADED-  .10 
ENTER  THE  #  OF  BLUE  EU  MISSIONS  REQUESTED  (MAX=50) 

20 

CHANGE  EW  PRIORITY? 

N 

CHANCE  ROLL  WAS  3 
CHANCE  ROLL  WAS  5 
CHANCE  ROLL  WAS  6 

PERCENT  REDADA  FP  SCORE  DEGRADED-  .60 
PERCENT  REDAH  FP  SCORE  DEGRADED-  .10 

PERCENT  REDARTY  FPS  i  MISSIONS  DEGRADED-  .60 
PERCENT  REDMNV  FP  SCORE  DEGRADED-  0.00 

IS  BLUE  EMPLOYING  SMOKE? 

Y 

ENTER  PERCENT  (DECIMAL)  OF  RED  SMOKED 

.2 

ENTER  PERCENT  (DECIMAL)  OF  SELF  SMOKED 

.8 

IS  RED  EMPLOYING  SMOKF? 

Y 

ENTER  PERCENT  (DECIMAL)  OF  BLUE  SMOKED 

.2 

ENTER  PERCENT  (DECIMAL)  OF  SELF  SMOKED 
0 

ENTER  TYPE  OF  RED  SMOKE- 
999 

ENTER  1  for  WP  OR  IF  ONLY  SELF  OBSCURING  SMOKE  IS  EMPLOYED,  ENTER  2  FOR 
OTHER  TYPE  SMOKE. 

ENTER  TYPE  OF  RED  SMOKE- 
1 

ENTER  TERRAIN  TYPE 
999 

FOR  OPEN  TERRAIN... . ENTER  1 

ROLLING  TERRAIN . . ENTER  2 

HILLY  TERRAIN . ENTER  3 

MOUNTAINOUS  TERRAIN _ .....ENTER  4 

ENTER  TERRAIN  TYPE 
2 


Figure  8-5.  Rate  of  Advance  (continued) 
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ENTER  VISIBILITY  FACTOR 
1 

IS  THIS  A  DAY  BATTLE? 

Y 

WILL  NEW  ARMOR  BE  FULLY  USED? 

Y 

IS  ATTACKER  MOUNTED 

Y 

ENTER  FRACTION  OF  SECTOR  ATTACKER  MASSED  (MAX-1) 
.5 

ENTER  HOLDING  FIREPOWER  RATIO-  0  MIN  a  2 

.6 

ARE  MINES  EMPLOYED  IN  THIS  SECTOR 

Y 

SHOULD  TIME  OR  DISTANCE  BE  HELD  CONSTANT 
999 

FOR  CONSTANT  TIME. .... .ENTER  1 

CONSTANT  DISTANCE.. ENTER  2 
SHOULD  TIME  OR  DISTANCE  BE  HELD  CONSTANT 
1 

ENTER  ATTACK  TIME  IN  HOURS  (MAX  24) 

6 

RATE  OF  ADVANCE 


MANEUVER  FP  SCORE . . .  11133./' 

FIRE  SUPPORT  FP  SCORE . .  3104./ 

TOTAL  FP  SCORE . 14237./ 

FP  RATIO  IN  SECTOR'S  MAIN  ATTACK  AREA .  1.8 

TOTAL  FP  RATIO . 1.2 

MANEUVER  FP  RATIO . .  1.2 

FIRE  SUPPORT  FP  RATIO.. . . .  1.2 

RATE-OF-AOVANCE  (KPH) .  .62 

DURATION  OF.  ATTACK  (HR)../ . 6.0 

DISTANCE  ADVANCED  (KM) . 3.7 


Figure  8-5.  Rate  of  Advance  (concluded). 
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2529. 

12102. 


B-6.  COMBAT  ASSESSMENTS.  Following  a  successful  run  of  the  rate  of  ' 
advance  routine,  the  combat  assessments  can  be  initiated  by  entering  a  "3“ 
at  the  DECISION  POINT.  Losses  can  be  determined  for  <  different  types 
of  combat  in  the  Jiffy  Game.  These  combat  types,  in  t  -  order  processed, 
are:  1)  TACAIR,  2)  indirect  fire,  3)  mines,  4)  armor/ ar,*i armor,  5) 
infantry,  and  6)  attack  helicopter/air  defense.  As  in  the  rate  of  advance 
calculations,  all  combat  losses  assessments  are  based  on  the  weapon  system 
array  displayed  in  figure  B-3.  A  sample  run  of  each  combat  assessment  is 
presented  and  discussed  in  the  following  subparagraphs. 

a.  TACAIR.  When  a  "3"  Is  input  for  the  DECISION  POINT,  the  first 
combat  losses  to  be  addressed  are  TACAIR.  The  Jiffy  Game  does  not  make 
the  actual  attrition  calculations  for  TACAIR  combat;  a  model  called 
TACCOM/TALON  (see  reference  1  and  2),  developed  and  run  by  the  US  Air 
Force,  is  used  to  determine  TACAIR  combat  losses.  The  Jiffy  Game  simply 
accepts  as  direct  input  the  cumulative  losses,  by  weapon  type,  output  from 
the  TACCOM  model  as  Illustrated  In  figure  3-6.  The  net  result  gf  this 
sample  run  is  the  loss  (subtraction)  of  one  weapon  type  21  from  the  Blue 
force.  When  all  TACAIR  losses  have  been  entered,  the  program  proceeds  to 
a  subsequent  combat  assessment  routine  with  no  interveni;  g  DECISION  POINT. 


???  D  £  C  I  S  I  0  N  P  0  I  N  T  ??? 

3 

DO  YOU  WISH  TO  INCLUDE  ANY  LOSSES  DUE  TO  TACAIR  FOR  APPORTIONMENT? 

Y 

ANY  BLUE  LOSSES? 

Y 

ENTER  WPN  ID,#  LOST  (0,0  WHEN  00NE)~ 

21,1 

NEXT- 

0,0 

ANY  RED  LOSSES? 

N 


Figure  B-6.  TACAIR  Losses. 


b.  Indirect  Fire.  After  the  T*CAIR  losses,  if  any,  have  been 
entered,  the  program  proceeds  to  checking  the  weapon  system  array  for 
indirect  fire  weapons.  If  none  are  found,  the  program  proceeds  t.o  a 
subsequent  assessment;  should  either  ?orce  contain  any  indirect  fire 
weapons,  the  indirect  fire  combat  assessment  routine  is  entered.  A  sample 
run  of  this  routine  is  given  in  figure  3-7.  As  with  all  combat 
assessment,  the  first  input  determines  whether  or  not  the  type  of  combat 
being  considered  is  to  be  processed.  In  the  example  of  figure  B-7,  the 
indirect  fira  assessments  are  to  be  processed  and  the  program  proceeds  to 
request  inputs  needed  to  calculate  losses.  Again,  all  possible  inputs 
have  been  illustrated  in  this  example  although  some  might  not  be  asked  for 
at  times.  Fo~  example,  if  the  response  to  "ENTER  #  MINUTES  OF  PREP  FIRE 
(0-60)**  is  "0"  (zero),  the  next  entry  specifying  minutes  of  counterprep 
fire,  would  not  be  asked.  Also,  the  question  "WILL  ATTACKER  DISMOUNT 
INFANTRY  DURING  THIS  Cl?", is  omitted  whenever  it  Is  specified  in  the  rate 
of  advance  routine  that  the  attacker's  infantry  forces  are  not  mounted 
(see  figure  8-4).  Finally,  the  entry  of  the  number  of  CLGP  missions  to 
fire  Is, only  required  when  the  Blue  weapon  system  array  contains  the 
appropriate  indirect  fire  weapons.  There  are  only  two  indirect  fire 
weapons  capable  of  firing  CLGP  missions;  in  this  example,  one  of  tnese 
sytems  w«s  included  in  the  Blue  force  array.  If  both  were  in  the  weapon 
array,  two  separate  Inputs  would  have  been  required.  Before  the  display 
of  assessments  the  program  prints  whether  artillery  caused  no,  light,  or  , 
heavy  dust  effects.  After  all  the  different  type  assessments  have  been 
displayed,  the  user  must  Indicate- whether  the  losses,  as  displayed,  should 
be  subtracted  from  the  force.  This  option,  which  Is  presented  at  the  end 
of  each  assessment  routine,  allows  the  user  to  disregard  a  "bad"  run 
(e.g.,  an  incorrect  input  may  have  been  entered),  and  the  routine  can  then 
be  processed  again  at  a  later  time. 
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DO  YOU  WISH  TO  PROCESS  INDIRECT  FIRE  ASSESSMENTS? 

Y 

INDIRECT  FIRE  ASSESSMENTS 

ENTER  PERCENT  (DECIMAL)  122  SP  HOWITZERS  USED  IN  DF  ROLE 

.2 

IS  BLUE  EMPLOYING  SMOKE? 

Y 

ENTER  PERCENT  MISSIONS -DEGRAD  OF  BLUE  SMOKE  EMPLOYERS 

.2 

IS  RED  EMPLOYING  SMOKE? 

Y 

ENTER  PERCENT  MISSIONS  OESRAO  OF  RED  SMOKE  EMPLOYERS 

.2 

ENTER  3  BLUE  ARTY  FIRING  LEVELS  (C8T  SPT.AD  SUP,  CTR-BTRY} 

999 

INCORRECT  ENTRY  -  TRY  AGAIN 
ENTER  0  FOR  NO  FIRES 

1  FOR  LIGHT  INTERMITTENT  FIRES 

2  FOR  FIRES  8ASE0  ON  2/3  BASIC  LOAO 

3  FOR  FIRES  BASED  ON  TOTAL  BASIC  LOAD 

4  FOR  FIRES  BASED  ON  DAILY  RESUPPLY  RATE 

•  5  FOR  FIRES  BASED  ON  DAILY  RESUPPLY  RATE  PLUS  THE  BASIC  LOAD 
6  FOR  APPROX.  SUSTAINED  RATE  OF  FIRE 
ENTER  3  BLUE  ARTY  FIRING  LEVELS  (C3T  SPT,  AO  SUP,  CTR-BTRY)  - 
4  4  4 

ENTER  3  RED  ARTY  MULTIPLIERS  (C8T  SPT,  AO  SUP,  CTR-BTRY)  - 

.2  .2  .2 

ENTER*#  HOURS  OF  ARTY  SUPPORT  (0-6.) 

6 

ENTER  #  MINUTES  OP  PREP  FIRE  (0-60) 

10 

ENTER  #  MINUTES  OF  COUNTER-PREP  FIRES  (0-60) 

10 

ENTER  #  MINUTES  OF  FINAL  PROTECTIVE  FIRE  (0-60) 

•.o 

WILL  ATTACKER  DISMOUNT  INFANTRY  DURING  THIS  Cl? 

Y 


Figure  8-7.  Sample  Run  of  Indirect  Fire  Assessments  (continued  next  page) 
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IS  AN  AERIAL  DESIGNATOR  IN  USE? 

Y 

ENTER  #  CLGP  MISSIONS  TO  FIRE  (MAX-23)  - 
10 

ENTER  CLOUO  HEIGHT  -  (0-5) 

999 

ENTER  0  IF  RANGE  IS  LESS  THAN  1500  FT 

ENTER  l  IF  RANGE  IS  150C-1999  FT 

ENTER  2  IF  RANGE  IS  2000-2499  FT 

ENTER  3  IF  RANGE  IS  2500-2999  FT 

ENTER  4  IF  RANGE  IS  3000-4499  FT 

'  ENTER  5  IF  RANGE  IS  4500  FT  OR  MORE 
ENTER  CLOUO  HEIGHT-  (0-5) 

2 

LIGHT  DUST  EFFECTS 

INDIRECT  FIRE  ASSESSMENTS 

RED  LOSSES  TO  BLUE  BLUE  LOSSES  TO  RED 


ITEM 

#LOST 

CREW 

ITEM 

ILOST 

CREW 

1 

.9 

1 

.4 

2 

46.6 

2 

16.6 

3 

7.0 

3 

.5 

6 

7.0 

6 

.5 

13 

3.9 

7.8 

13 

.4 

.8 

16 

.2 

.f 

21 

.1 

.2 

21 

.8 

1.6 

29  ■ 

.2 

.4 

25 

.2 

.4 

32 

.1 

.3 

29 

.5 

1.5 

31 

.5 

2.0 

36 

.1 

.2 

43 

3.3 

13.2 

37 

1.7 

1.7 

46 

.1 

.5 

39 

.4 

3.2 

50 

.1 

1.0 

43 

4.6 

23.0 

46 

.4 

0.0 

SO 

.6 

4.8 

DO  YOU  WISH  TO  SUBTRACT  LOSSES  FROM  FORCE  STRUCTURES? 
Y 


Figure  8-7.  Sample  Run  of  Indirect  Fire  Assessments  (concluded) 


c.  Mines.  Following  the  indirect  fire  assessment,  the  program  checks 
whether  mines  are  employed  in  the  Cl  being  gamed  as  specified  in  rate  of 
advance  (see  figure  8-5).  If  so,  the  minefield  assessment  routine  is 
entered  for  processing.  A  sample  run  of  this  routine  is  given  in  figure 
8-8.  Inputs  for  both  a  conventional  and  a  FASCAM  minefield  assessment  are 
demonstrated.  For  the  conventional  case,  the  example  specifies  that  the 
Blue  force  does  have  the  capability  to  employ  mechanical  mine  planters. 

If  mechanical  planters  are  not  used,  the  entries  for  the  nunber  of 
platoons  and  for  the  number  of  hours  are  not  made.  In  their  place,  three 
different  Inputs  are  required  for  the  following:  1)  “ENTER  NUM8ER  OF  MEN 
USED  TO  EMPLACE  MINES  (MAX*1000)“,  2)  “ENTER  HOURS  AVAILABLE  FOR 
EMPLACEMENT  OF  MINES  (MAX»300)“ ,  and  3)  “SELECT  MINEFIELD  DENSITY-.  For 
minefield  density,  a  selection  is  made  from  five  different  specified 
values,  which  range  from  .0013  to. 0200  mines/sq  meter.  For  the  FASCAM 
assessment,  the  input  requirements  are  always  as  shown  in  the  sample  run 
regardless  of  the  type  delivery  specified.  The  method  of  delivery  entered 
for  FASCAM  cause?  the  program  to  access  the  correct  data  (e.g..,  casualty 
rates)  in  making  the  loss  calculations.  It  should  be  noted  that  only  the 
defending  force  can  emplace  minefields.  In  this  example,  the  Blue  force 
has  been  designated  as  the  defender  In  rate  of  advance  (see  figure  B-4); 
therefore,  the  attacker  losses  displayed  in  figure  3-3  are  to  the  Red 
force.  Another  point  to  emphasize  Is  that  the  minefield  routine  is  not 
exited  until  a  "0“  (zero)  is  entered  for  “SELECT  TYPE  OF  MINE  EMPLOYMENT". 
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DO  YOU  WISH  TO  PROCESS  MINE  ASSESSMENTS? 
Y 

SELECT  TYPE  OF  MINE  EMPLOYMENT 


999 

FOR  CONVENTIONAL  MINES . ENTER  1 

FASCAM  MINES . ENTER  2 

***TO  END*** . ENTER  0 


SELECf  TYPE  OF  MINE  EMPLOYMENT 
1  . 

ARE  MINES  LAIO  PRIOR  TO  COMMENCEMENT  OF  HOSTILITIES? 

Y 

WILL  BLUE  HAVE  THE  CAPABILITY  TO  EMPLOY  MECHANICAL  MINE  PLANTERS? 

Y 

ENTER  NUM8ER  OF  MECHANICAL  MINE  PLANTER  PLATOONS  (MAX  30) 

3 

ENTER  NUMBR  OF  AVAILABLE  MINE  PLANTER  HOURS  (MAX  300) 

24 

POTENTIAL  MINEFIELD  FRONTAGE  IS  21600. 

ENTER  ACTUAL  VF  FRONTAGE  (MAX-POTENTIAL) 

1500 

ENTER  FRACTION  OF  MINE  FIELD  NOT  BYPASSED  BY  ATTACKER  (MAX-1.0) 

.6 

ENTER  AMOUNT  OF  TRAFFICABLE  TERRAIN  (  900.-100000.  M) 

7000 

ENTER  AP  MINE  DENSITY  (SQ  METER)  -  (MIN-.013-MAX-.160) 

ENTER  PERCENT  (DECIMAL)  OF  FORCES  ENTERING  MF  (MAX-.5) 

.25 


MINEFIELD  ASSESSMENTS 

ATTACKER  LOSSES 
ITEM  #L0ST  CREW 

2  1.2 

3  .6 

6  .6 

16  .1  .3 

21  .1  .2 

29  .1  .3 

31  .1  .4 

Figure  8-8.  Sample  Run  of  Minefield  Assessments  (continued  next  page) 


SELECT  TYPE  OF  MINE  EMPLOYMENT 

SELECT  TYPE  OF  FASCAM  DELIVERY 

FOR  ARTILLERY . \ 

GEMMS  •  •••••••••♦••••••*•* £ 

SELECT  TYPE  OF  FASCAM  DELIVERY 

ENTER  MINEFIELO  FRONTAGE  (MAX*  lOOOOO) 

ENTER  FRACTION  OF  MF  NOT  BYPASSED  BY  ATTACKER  (MAX*1.) 

ENTER  AMOUNT  OF  TRAFFICABLE  TERRAIN  (  900.-100000.  M) 

ENTER  PERCENT  (QECIMAL)  OF  FORCE  ENTERING  MF  (MAX*. 5) 

.25 

FASCAM  ASSESSMENTS 

ATTACKER  LOSSES 
ITEM  #LOST  CREW 


2 

1.2 

3 

.6 

6 

.6 

.3 

16 

.1 

21 

.1 

.2 

29 

.1 

.3 

31 

.1 

.4 

SELECT  TYPE  OF  MINE  EMPLOYMENT 

00  YOU  WISH  TO  SUBTRACT  LOSSES  FROM  FORCE  STRUCTURES'! 


Figure  3-8.  Sanple  Run  of  Minefield  Assessments  (concluded) 


d.  Armor/Anti  armor.  Following  the  minefield  assessment.  If  either 
force  contains  tanks  (armor)  or  antitank  weapon  systems,  the 
armor/ anti  armor  assessment  routine  is  entered.  As  shown  In  figure  B-9, 
this  routine  requires  minimal  inputs  from  the  user.  The  primary 
requirements  are  to  enter  a  range  index  between  attacker  and  defender,  the 
percent  of  armor/antiarmor  committed  and  the  percents  of  weapons  obscured 
by  smoke  at  this  range.  Multiple  assessments  can  be  made  by  entering 
another  non-zero  range  Index  each  time  the  program  returns  to  that  Input 
point;  assessments  are  not  stopped  until  a  "0“  Is  entered  for  the  range 
Index.  The  999  input  In  figure  B-9  shows  that  one  of  six  different 
Specified  range  bands  can  be  entered  for  the  range  index  (excluding 
zero).  The  maximum  range  between  attacker  and  defender  (3,000  +  meters) 
corresponds  to  the  greatest  distance  at  which  the  opposing  forces  would 
engage  in  direct  fire  combat  under  ideal  conditions  of  visibility.  The 
visibility  level  for  the  combat  assessments  is  specified  by  the  user  in 
the  rate  of  advance  and  has  been  set  to  100  percent  for  this  sample  run 
(see  figure  B-5).  Under  less  than  ideal  visibility  conditions  the  maximum 
range  for  armor/antiarmor  engagement  is  decreased.  For  instance,  under 
the  poorest  visibility  conditions  allowed,  a  "1"  (500  meters)  is  the  only 
non-zero  input,  accepted. 


DO  YOU  WISH  TO  PROCESS  ARMOR /ANT I ARMOR  ASSESSMENTS? 

Y 

00 ES  THE  M60A3  HAVE  THERMAL  SIGHTS? 

Y 

ENTER  RANGE  INDEX  BETWEEN  ATTACKER  &  DEFENDER 
999 

IF  RANGE  IS  BETWEEN: 

3000  &  2501  ENTER  5 
2500  &  2001  ENTER  5 
2000  &  1501  ENTER  4 
1500  &  1001  ENTER  3 
1000  &  501  ENTER  2 
500  &  0  ENTER  1 

**T0  STOP**  ENTER  0 

ENTER  RANGE  INDEX  BETWEEN  ATTACKER  &  DEFENDER 

1 

ENTER  PERCENT  OF  BLUE/ARMOR/ANTIARMOR  COMMITTED 

.9 

ENTER  PERCENT  OF  RED  ARMOR/ ANT I ARMOR  COMMITTED 
.9 

IS  BLUE  EMPLOYING  SMOKE? 

Y 

ENTER  PERCENT  (DECIMAL)  RED  WEAPONS  OBSCURED 

.2 

ENTER  PERCENT  (DECIMAL)  OF  SELF  SMOKED 

.1 

IS  RED  EMPLOYING  SMOKE? 

Y 

ENTER  PERCENT  (OECIMAL)  BLUE  WEAPONS  OBSCURED 

.2 

ENTER  PERCENT  (OECIMAL)  OF  SELF  SMOKED 

.1 


BLUE  LOSSES  TO  THIS  POINT 


ITEM 


#  LOST 


2 

14.3 

3 

3.4 

,  11 

.1 

13 

1.1 

16 

2.2 

21 

1.8 

29 

1.8 

32 

.9 

Figure  8-9. 

Sampl  e 

Sample  Run  of  Armor/ Anti  armor  assessments  (continued) 


TO  THIS  POINT 
#  LOST 
37.3 
19.8 
19.8 
.6 
3.2 
3.1 
.4 
2.9 
3.0 

ENTER  RANGE  INDEX  BETWEEN  ATTACKER  &  OEFENDER 
0 


ARMOR  ASSESSMENTS 

TOTAL  RED  LOSSES 

ITEM 

#  LOST 

CREW 

2 

37.3 

3 

19.8 

6 

19.8 

11 

.6 

16 

3.2 

9.6 

21 

3.1 

6.2 

25 

.4 

.8 

29 

2.9 

8.7 

31 

3.0 

12.0 

TOTAL 

.  BLUE  LOSSES 

ITEM 

#  LOST 

CREW 

2 

14.3 

, 

3 

3.4 

11 

.1 

13 

1.1 

2.2 

16 

2.2 

2.2 

21 

1.8 

3.6 

29 

1.8 

3.6 

32 

,  .9 

2.7 

DO  YOU  WISH  TO  SUBTRACT  LOSSES  FROM  FORCE  STRUCTURES? 

Y 

Figure  8-9.  Sample  run  of  armor/ anti  armor  assessments  (concluded) 


RED  LOSSES 
ITEM 
2 
3 
6 
11 
16 
21 
25 
29 
31 
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e.  Infantry.  When  the  armor/ anti  armor  assessments  are  finished,  the 
program  proceeds  to  the  infantry  combat  routine.  Infantry  assessments  can 
be  processed  only  if  both  forces  contain  infantry  personnel  In  the  weapon 
system  array;  otherwise,  it  is  bypassed.  The  sample  run  of  this  routine 
Is  given  in  figure  B-IO.  The  Input  requirements  are  straightforward;  the 
only  variation  in  the  user  responses  shown  occurs  when  ambush  tactics  are 
not  employed,  in  which  case  the  question  “IS  BLUE  AMBUSHING  RED"  is 
omitted.  There  is  no  multiple  assessment  capability  for  Infantry  combat. 
The  Inputs  set  the  necessary  parameters  for  the  entire  infantry  battle 
being  gamed,  the  losses  are  calculated  and  displayed,  and  the  routine  Is 
ended. 


00  YOU  WISH  TO  PROCESS  INFANTRY  ASSESSMENTS? 

Y 

INFANTRY  ASSESSMENTS 

ENTER  FRACT  OF  BLUE  MANEUVER  FORCES  COMMITTED  (MAX  1.) 

.8 

ENTER  FRACT  OF  RED  MANEUVER  FORCES  COMMITTED  (MAX  1.) 

.8 

DO  TANKS  SUPPORT  THE  DISMOUNTED  INFANTRY  IN  THIS  SECTOR 

Y 

ENTER  #  HOURS  OF  INFANTRY  ATTACK  (MAX  *  6.). 

2.5 

ARE  AMBUSH  TACTICS  BEING  EMPLOYED 

Y 

IS  BLUE  AMBUSHING  RED 

Y 

RED  INFANTRY  LOSSES 
ITEM  #LOST 

3  56.9 

1  2.8 


BLUE  INFANTRY  LOSSES 
ITEM  #LOST 

1  .1 

3  4.9 

6  4.9 

11  .2 

,  DO  YOU  WISH  TO  SUBTRACT  LOSSES  FROM  FOURCE  STRUCTURES? 
Y 


Figure  3-10.  Sample  Run  of  Infantry  Assessments. 
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f.  Attack  Helicopter/Air  Defense.  The  last  type  of  combat  to  be 
addressed  for  assessments  is  attack  helicopter/ air  defense.  This  routine 
is  entered  following  completion  of  the  infantry  combat  processing  if 
either  force  contains  attack  helicopters.  The  sample  run  In  figure  B-ll 
demonstrates  the  input  requirements  for  completing  the  helicopter  and  air 
defense  assessments.  The  user  Is  first  given  the  opportunity  to  game  Blue 
AOA/Red-AH,  then  vice  versa.  The  Inputs  are  essentially  the  same  in  both 
cases,  except  for  Blue  AH  the  user  must  select  the  missile  fire  launch 
method.  All  possible  user  responses  are  demonstrated  in  figure  B-ll.  It 
should  be  noted  that  the  use  of  the  Red  helicopters  Illustrates  the 
capability  of  the  user  to  abort  a  helicopter  mission  before  its 
completion,  if  helicopter  losses  exceed  30  percent.  In  the  Blue  case  in 
figure  B-ll,  the  mission  Is  assessed  to  its  notmal  completion  since  losses 
to  the  helicopter  cell  remain  below  30  percent.  The  cycle  of  defining  and 
assessing  helicopter  cells  can  be  continued  until  all  sorties  have  been 
depleted  or  all  the  helicopters  killed.  The  user  determines  when  the 
assessments  for  each  hell copter/ air  defense  combination  are  terminated. 
Upon' completion  of  this  routine,  the  program  returns  to  the  DECISION  POINT. 


DO  YOU  WISH  TO  PROCESS  AIR  DEFENSE/ARMED  HELICOPTER  ASSESSMENTS? 

Y 

AIR  OEFENSE/ARMED  HELICOPTER  ASSESSMENTS 
DO  YOU  WISH  TO  GAMnCOFTO  ANO  RED  A/C? 

Y 


THE  FOLLOWING  SETS  PARAMETERS  FOR  BLUE  AD  WEAPONS 
ENTER  BLUE  WEAPON  CONTROL  (STATUS)  FACTOR - 


999 

FOR  WEAPON  FREE .  ENTER  1 

WEAPON  TIGHT  .  ENTER  2 


WEAPON  HOLD  ENTER  3 

ENTER  BLUE  WEAPON  CONTROL  (STATUS)  FACTOR- 


IS  DEFENDER  IN  HIGH  DENSITY  SECTOR  (BN  <4  KM)? 

Y 

ENTER  PRIORITY  WEIGHTING  FACTOR  FOR  BLUE  ADA  TARGETS  (MAX=5) 
5 


THE  FOLLOWING  SETS  PARAMETERS  FOR  RED  HELICOPTERS 

ENTER  TOTAL  FLYING  TIME  FCR  RED  A/C  THIS  Cl  (MAX*  6.0  HOURS)- 
6 

BEGIN  BUILDING  CELLS  OF  RED  A/C  TO  aY  AGAINST  BLUE  GROUND  FORCES 

TOTAL  RED  A/C  ANO  SORTIES  AVAILABLE  ThlS  Cl 

A/C  TYPE 

#  A/C  #  SORTIES 

62 

8.  49. 

63 

8.  49. 

ENTER  A/C  ELMT  #,NQ. 

AOOED  (+  OR  -)  TO  CELL-0,0  TO  STOP- 

62,8 

, 

NEXT  ENTRY- 

. 

63,8 

NEXT  ENTRY- 

. 

0,0 

ENTER  STANDOFF  RANGE 

INDEX- 

999 

IF  RANGE  IS  500  ENTER  1 

1000 

2 

1500 

3 

2000 

4 

2500 

5 

3000 

6 

3500 

7 

4000. 

3 

4500 

9 

5000 

10 

Figure  8-11.  .Sample  Ru’  of  Attack  Hell copter /Air  Defense  Assessments 

(continued  next  page). 
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ENTER  STANDOFF  RANGE  INOEX- 
3 

LOSSES  EXCEED  30X  AFTER  9  POPUPS 
DO  YOU  WISH  TO  SEE  LOSSES? 

Y 

RED  HELICOPTERS  KILLED 


TYPE 

#  KILLED 

62 

2.6 

63 

2.5 

BLUE  GROUND  FORCES  KILLED 

TYPE 

#  KILLED 

16 

3.9 

21 

3.7 

29 

1.1 

32 

5.0 

39 

5.1 

DO  YOU  WISH  TO  ABORT  THIS  SORTIE? 

Y 

DO  YOU  WISH  TO  FLY  ANOTHER  CELL  OF  RED  A/C? 

N 

DO  YOU  WISH  TO  GAME  RED  ADA  AND  BLUE  A/C? 

Y 

THE  FOLLOWING  SETS  PARAMETERS  FOR  RED  AD  WEAPONS 


ENTER  RED  WEAPON  CONTROL  (STATUS)  FACTOR- 
1 

ENTER  PRIORITY  WEIGHTING  FACTOR  FOR  RED  ADA  TARGETS  (MAX*5)- 
5 


Figure  8-11.  Sample  Run  of  Attack  Helicopter /Air  Defense  Assessments 

(continued). 
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THE  FOLLOWING  SETS  PARAMETERS  FOR  BLUE  HELICOPTERS 

ENTER  TOTAL  FLYlNl  TIME  FOR  BLUE  A/C  THIS  Cl  (MAX*  6.0  HOURS) - 
6 

BEGIN  BUILDING  CELLS  OF  BLUE  A/C  TO  FLY  AGAINST  RED  GROUND  FORCES 

TOTAL  BLUE  A/C  AND  SORTIES  AVAILABLE  THIS  Cl 
A/C  TYPE  #A/C  #  SORTIES 

■  61  8.  49. 

62  8.  49. 

ENTER  A/C  ELMT  #,N0  ADDED  {  +  OR  -)  TO  CELL— 0,0  TO  STOP 
61,8 

PiXT  ENTRY- 
62,8 

NEXT  ENTRY- 

0,0 

ENTER  AH  MISSILE  FIRE  LAUNCH  METHOD- 
999 

FOR  INDIRECT  FIRE  LAUNCH  . ENTER  1 

FOR  DIRECT  FIRE  (AUTO  OR  REMOTE  CONTROL).... ENTER  2 
ENTER  AH  MISSILE  FIRE  LAUNCH  METHOD- 
1 

ENTER  STANDOFF  RANGE  INOEX- 
3 

15  POPUP  SORTIE  COMPLETED. 

DO  YOU  WISH  TQ  SEE  LOSSES? 

Y 


BLUE  HELICOPTERS  KILLED 
TYPE  #  KILLED 

62  1.8 

RED  GROUND  FORCES  KILLED 
TYPE  #  KILLED 

16  2.2 

21  .7 

29  .2 

31  2.6 

39  1.1 

00  YOU  WISH  TO.  FLY  ANOTHER  CELL  OF  BLUE  A/C? 

DISPLAY  LOSSES? 

Y 

Flgur*  8-11  Sample  Run  of  Attack  Hellcopter/AIr  Defense  Assessments 

(continued) 
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ah/aq  assessments 


TOTAL 

BLUE  LOSSES 

ITEM 

#  LOST 

CREW 

2 

59.2 

13 

5.9 

11.7 

16 

3.9 

3.9 

21 

3.7 

7.5 

29 

1.1 

2.2 

32 

5.0 

14.9 

39 

5.1 

15.3 

62 

1.8 

3.7 

TOTAL 

RED  LOSSES 

item 

#  LOST 

CREW 

2 

26.4 

3 

4.2 

6 

4,2 

11 

.2 

16 

2.2 

6.5 

21 

.7 

1.4 

29 

.2 

.6 

31 

2.6 

10.2 

39 

1.1 

a. 9 

62 

2.6 

5.3 

63 

2.5 

5.1 

DO  YOU  WISH  TO, SUBTRACT  LOSSES  FROM  FORCE  STRUCTURES? 


Figure 


8-12  Sample  Run  of  Attack  Hell copter/AIr  Defense  Assessments 

(concluded) 
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8-7.  LOSS  APPORTIONMENT.  After  all  the  combat  has  been  assessed  In  the 
Jiffy  Game,  the  losses  that  resulted  must  be  apportioned  to  the  units  that 
were  loaded  into  sector  “1"  of  critical  incident  "TEST".  The  remaining 
weapon  systems  may  be  displayed  through  the  entry  of  DECISION  POINT  6, 
figure  8-12 ) .  The  user  accomplishes  the  loss  apportionment  through 
DECISION  POINT  4.  figure  3-13  contains  the  sample  run  of  the  loss 
apportionment.  The  user  can  change  the  combat  intensity  level  of  any 
units  before  the  apportionment  is  made.  The  combat  intensity  level  of  a 
unit  can  be  changed  permanently  by  adding  10  to  the  new  level.  Thus  a 
“4'’,  for  example,  in  response  to  enter  new  combat  intensity  would  change 
the  level  of  the  unit  for  the  current  apportionment  only,  while  a  "14" 
would  change  the  level  of  the  unit  permanently  on  the  force  file.  An 
apportionment  message  is  displayed,  which  indicates  that  there  is  an 
insufficient  number  of  Red  type  2  weapons  to  be  properly  apportioned.  The 
apportionment  of  these  types  of  weapons  must  be  Ignored.  This  situation 
occurs  generally  to  small  arms  and  other  dismounted  infantry  systems.  The 
assessment  of  these  weapons  Is  based  on  Infantry  casualties  ar.d  not  the 
number  of  weapons  actually  engaged  In  combat.  At  this  point,  each  unit  is 
subjected  to  the  loss  apportionment  algorithm,  and  its  resulting  unit 
effectiveness  is  displayed  as  shown  In  figure  8-13 .  At  the  same  time  a 
more  comprehensive  output  of  each  unit,  the  nanber  and  type  of  weapons  It 
lost,  and  the  number  and  type  of  weapons  remaining  In  the  unit  Is  written 
on  the, STATS  file,  a  detailed  file  on  the  combat  statistics.  This  portion 
of  the  STATS  file  Is  known  as  the  UNIT  STATUS  (see  appendix  C).  After  the 
losses  have  been  apportioned  to  all  units  gamed,  the  user  has  the 
capability  to  display  any  unit  and  the  weapons  that  remain  In  it.  Figure 
B-13  also  illustrates  the  use  of  decision  point  12.  This  run  was  made  by 
adding  12,  1  and  the  apportionment  answers  at  the  end  of  a  previous  file 
of  answers  through  the  assessment  process.  Figure  3-13  illustrates  the 
use  of  answers  12  and  2  to  disconnect  the  output  of  the  start  of  a  run. 

If  it  Is  not  connected  previously,  output  Is  always  connected 
automatically  at  the  end  of  a  file  of  answers,  when  a  question  is  asked 
requiring  an  interactive  response. 


FORCE  STRUCTURES 


ELEMENT 

BLUE 

RED 

1 

99. 

98. 

2 

12. 

0. 

3 

31. 

26. 

5 

100. 

100. 

6 

95. 

26. 

11 

10. 

7. 

13 

3. 

6. 

16 

4. 

4. 

21 

3. 

5, 

39 

7. 

6. 

31 

0. 

4, 

32 

4. 

0, 

36 

10. 

0, 

37 

0. 

8 

39 

5. 

9 

43 

7. 

5, 

46 

10. 

10 

50 

10. 

9 

61 

10. 

0 

62 

8. 

7 

63 

0. 

8 

Figure  3-12  Weapon  Systems  After  Attrition  Process 


SPECIFY  PURPOSE  OF  THIS  RUN 

???  0  E  C  I  S  I  0  N  POINT??? 

12 

ENTER  OPTION  -  1  TO  CONNECT;  2  TO  OISCONT 
2 

???  0  E  C  I  S  I  0  N  POINT??? 

4 

DO  YOU  WISH  TO  CHANGE  COMBAT  INTENSITY  LEVEL  FOR  ANY  UNIT? 

Y 

ENTER  PARENT  ID  - 
1 

ENTER  UNIT  ID- 
11 

ENTER  NEW  COMBAT  INTENSITY  - 

5 

DO  YOU  WISH  TO  CHANGE  COMBAT  INTENSITY  LEVEL  FOR  ANY  UNIT? 

N 

INSUFFICIENT  C8T  INTENSITY  LEVELS  HAVE  BEEN  ASSIGNED  FOR  ITEM  2  OF  RED 
FORCE  AUTO-ALLOCATION  OF  A80VE  WPN  SYSTEMS  HAS  BEEN  INITIATED 
EFFECTIVENESS  OF  11  »  63. 

EFFECTIVENESS  OF  12-94. 

EFFECTIVENESS  OF  13  -  94. 

EFFECTIVENESS  OF  14  -  41. 

CUMMULATIVE  EFFECTIVENESS  OF  1  -  72. 

EFFECTIVENESS.  OF  21  -  72. 

EFFECTIVENESS  OF  22  «  75. 

EFFECTIVENESS  OF  23  -  87. 

EFFECTIVENESS  OF  24  -  46. 

CUMMULATIVE  EFFECTIVENESS  OF  2  »  68. 

DISPLAY  A  UNIT? 

N 

???  D  E  C  I  S  I  0  N  POINT??? 

END  OF  ANSWER  FILE  -  INPUT  FROM  TERMINAL 
,  ???  0  E  C  I  S  I  0  N  POINT??? 


Figure  8-13.  Sample  Run  of  Loss  Apportionment. 
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8-8.  BATTLE  STATISTICS.  After  the  loss  apportionment  is  completed,  the 
user  should  always  exercise  DECISION  POINT  5,  which  outputs  to  the  STATS 
file  tre  remainder  of  the  battle  statistics  and  postprocessor  information 
as  discussed  In  appendix  C-  An  example  Is  given  in  figure  B-14.  In 
addition  to  the  standard  loss  exchange  ratios  (as  discussed  In  appendix  C) 
an  LER  Involving  only  Item  code  16  is  requested.  Besides  the  statistics 
for  the  current  sector,  cumulative  statistics  from  combinations  of 
previously  gamed  sectors  can  be  obtained,  if  desired. 


1*1  decision  point  ??? 

5  SECTOR  OUTPUT  FOR  SECTOR  1.  of  Cl  TEST 
OPTIONAL  LER? 

r 

ENTER  SLUE  WPN  (0  WHEN  DONE)- 
16 

NEXT- 

0 

ANOTHER  LER? 

N 

SELECT  OUTPUT  OPTION  (0  IF  DONE) - 

INPUT  OUTPUT  CREATED 

£  SINGLE  SECTOR 

3  R  CI  (MULTIPLE  SECT0R) 

s  .  (MULTI|,LE  ci> 

SELECT  OUTPUT  OPTION  (0  IF  DONE) - 


Figure  3-14.  Output  selection  In  sanple  run 
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8-9.  TERMINATION.  The  Jiffy  Gane  Is  ended  through  DECISION  POINT  9. 
Figure  8-15  is  an  example  of  termination  procedures.  The  user  Is  asked  if 
all  sectors  of  the  current  Cl  have  been  gamed.  A  negative  response  ends 
the  program  immediately.  An  affirmative  response  updates  the  history  file 
to  allow  another  Cl  to  be  gamed  at  DECISION  POINT  1,  when  the  program  is 
next  executed.  The  user  is  given  an  opportunity  to  obtain  cumulative 
statistics  and  postprocessor  information  for  the  whole  Cl  and  also  for  all 
CIs  so  far  gamed.  After  the  program  has  ended  the  STATS  file  should  be 
routed  to  a  high-speed  printer.  The  user  may  also  obtain  a  permanent 
record  of  the  questions  and  his  answers  during  the  current  run  by  routing 
the  QA  file  to  a  high-speed  printer. 

m  DECISION  POINT  ??? 

9 

HAS  THE  LAST  SECTOR  BEEN  GAMED  FOR  Cl  TEST  ? 

Y 

DO  YOU  WANT  Cl  STATS  OUTPUT  FOR  Cl  TEST  ? 

N 

DO  YOU  WANT  GAME  STATS  OUTPUT  THROUGH  Cl  TEST  ? 

N 


Figure  8-15  Termination  of  the  Sample  Run. 
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OUTPUT  FROM  JIFFY  GAME  SAMPLE  RUN 
(POSTPROCESSOR) 
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OUTPUT  FROM  JIFFY  GAME  SAMPLE  RUN 
(POSTPROCESSOR) 

C-l.  PURPOSE  AND  SCOPE.  This  appendix  discusses  and  provides 
examples  of  the  hard  copy  results  obtained  following  a  complete  run  of 
the  Jiffy  Game. 

C-2.  GENERAL.  During  execution  of  some  portions  of  the  Jiffy  Game, 
the  program  creates  a  file  containing  detailed  results  of  the  combat 
being  gamed.  This  Information  Is  not  displayed  on  the  console  screen 
by  the  program  but  Is  stored  in  the  local  file  area  of  the  terminal 
and  can  be  printed  out  on  a  high  speed  printer  after  the  program  is 
exited.  For  each  sector  of  combat  assessed,  two  major  types  of 
Information  are  made  available  to  the  user  by  this  process.  One  Is  a 
unit  status  file  of  the  forces  In  the  sector  and  the  other  is  a  series 
of  tables  giving  detailed  combat  loss  data  resulting  from  the 
assessments.  The  name  of  the  local  file  containing  these  data  Is 
STATS. 

C-3.  POSTPROCESSOR.  In  addition  to  the  sector  being  gamed, 
cumulative  data  can  be  obtained  using  Information  stored  on  the 
history  file  about  previously  gamed  sectors.  Thus,  the  Jiffy  program, 
with  the  history  file,  serves  as  a  postprocessor  that  will  assist  the 
analysts  and  gamers  working  with  the  Jiffy  war  games  In  studies.  Some 
of  the  measures  are  defined  In  the  following  several  sections. 

C-4.  UNIT  STATUS.  The  Input  of  a  "4"  at  the  DECISION  POINT  in  the 
Jiffy  Game  Initiates  the  apportioning  of  combat  assessment  losses  to 
the  individual  units  that  were  loaded  into  a  sector  as  demonstrated  in 
figure  B-13.  As  this  apportionment  is  being  made,  the  program  writes 
the  current  status  of  each  unit  and  each  parent  unit  to  the  STATS 
file.  Figure  C-l  Is  an  example  of  this  output. 

C-5.  FORCE  STRUCTURE.  The  force  structure  entered  In  the  current 
sector  is  obtained  from  the  force  structure  arr'ay  before  assessments 
are  calculated.  An  example  Is  shown  In  figure  C-2. 

C-6.  LOSS  AND  DAMAGE  DISTRIBUTION.  Figure  C-3  Is  an  example  of  the 
Loss  and  Damage  Distribution  table  for  the  current  sector  obtained 
when  the  user  answered  "Y"  after  DECISION  POINT  5  (see  figure  B-14). 
Several  other  loss  statistics  are  obtained  at  the  samfc  time  and 
discussed  below. 

C-7.  SOURCE  OF  LOSS.  Four  losses  by  category  of  source  of  loss  are 
obtained.  These  are  listed  below  and  are  shown  In  tables  a  and  d  In 


figure  C-4.  The  tables  for  b  and  c  are  similar  to  a  and  d  and  thus 
are  omitted. 

a.  Blue  losses  by  victim  type. 

b.  Blue  losses  by  victim  category. 

c.  Red  losses  by  victim  type. 

d.  Red  losses  by  victim  category. 

C-8.  KILLER-VICTIM  MATRICES.  The  Jiffy  output  generally  contains  13 
killer-victim  tables. 

a.  One  table  is  output  for  each  side  as  killer  In  each  of  the 
following  five  killer  categories. 

.  Armor. 

.  Artillery. 

.  Air  Defense. 

.  Helicopter. 

.  Infantry. 

One  table  Is  output  for  the  defender  mines  as  killer.  Finally,  two 
aggregated  matrices  are  produced. 

b.  Figure  C-5  Illustrates  the  Blue  armor  matrix  and  the  two 
aggregated  matrices. 

C-9.  AMMUNITION  EXPENDITURE.  Figure  C-6  gives  the  ammunition 
expenditures  of  both  Blue  and  Red  during  the  sample  run  In  appendix  B. 

C-10.  RATIO  STATISTICS. 

a.  Figure  C-7  consists  of  ratio  statistics  to  describe  combat 
results. 

b.  The  ratios  are  of  the  following  five  types. 

(1)  Loss  exchange  ratio  (LER).  This  Is  Red  losses  divided  by 
Blue  losses. 

(2)  Surviving  maneuver  force  ratio  {SMFR).  A  ratio  Is 
produced  for  each  side.  For  example,  for  Blue  the  SMFR  Is  Blue's 
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surviving  force  divided  by  Blue's  starting  force.  Current  usage  is 
not  restricted  to  traditional  maneuver  systems,  as  explained  in 
subparagaph  c  below. 

(3)  Surviving  maneuver  force  ratio  differential  (SMFRQ). 

This  is  SMFD  (Blue)  minus  SMFD  (Red). 

(4)  Initial  force  ratio  (IFR).  This  Is  the  Red  Initial  force 
divided  by  the  Blue  Initial  force. 

(5)  Force  exchange  ratio  (FER) .  This  Is  the  LER  divided  by. 

the  IFR. 

c.  The  weapons  systems  covered  In  these  ratios  in, the  set  of 
three  tables  (figure  C-7)  are: 

(1)  Major  weapon  systems  (Including  maneuver  elements,  all 
artillery,  and  helicopters). 

(2)  Armored  systems  only.  (Some  scenarios  may  not  count 
dismounted  antitank  weapons.) 

(3)  Optional  LER  (the  user  may  select  the  weapon  systems). 

d.  Each  of  these  tables  has  two  parts— in  the  first  the  systems 
count  equally  and  in  the  second  they  are  weighted  by  firepower  scores. 
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UNIT-  13 
EFF-  94. 

EL  ,  LOST  REMAIN 
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Figure  C-l 
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Unit  Status  File 
(continued  next  page). 
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UNIT  STATUS  FILE  FOR  Cl  TEST 

:  SECTOR  1. 

PARENT-2 

*★ 

UNIT-11 

EFF- 

68. 

** 

EFF- 

72. 

EL 

LOST 

REMAIN 

** 

EL 

LOST 

REMAIN 

1 

1.6 

98.4 

** 

31 

6.3 

3.7 

2 

127.9 

53.8 

** 

37 

1.7 

8.3 

3  . 

75.3 

24.7 

** 

39 

1.5 

8.5 

5 

0.0 

100.0 

2 

38.9 

0.0 

6 

75  3 

24.7 

** 

11 

3.0 

7.0 

frk 

13 

3.9 

6.1 

* * 

16 

5.8 

4.2 

\*k 

************ 

a******************* 

21 

4.8 

5.2 

*★ 

29 

3.8 

6.2 

wk 

UNIT5 

•  12 

31 

6.3 

3.7 

** 

EFF- 

94. 

37 

1.7 

8.3 

** 

39 

1.5 

8.5 

** 

EL  LOST 

REMAIN 

43 

4.6 

5.4 

** 

46 

.4 

9.6 

** 

62 

2.6 

7.4 

50 

1.2 

8.8 

** 

63 

2.5 

7.5 

62 

2.6 

7.4 

** 

2 

1C. 2 
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ONE  SECTOR  OUTPUT  FOR  Cl-  TEST 

:  S 

FORCE  STRUCTURE  ELEMENT 

BLUE 

RED 

1 

100. 

100. 

2 

100. 

100. 

3 

100. 

10Q. 

4 

100. 

100. 

5 

10Q. 

100. 

6 

100. 

A00. 

11 

10. 

10. 

13 

10. 

•3. 

15 

10. 

10. 

21 

10. 

10. 

29 

10. 

10. 

31 

0. 

10. 

32 

10. 

0. 

36 

10. 

0. 

37 

0. 

10. 

39 

10. 

10. 

43 

10. 

10. 

45 

10. 

10. 

50 

10. 

10. 

61 

10. 

0. 

62 

10. 

10. 

63 

0. 

10. 

Figure  C-2 

!.  Force  Structure 
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ONE  SECTOR  OUTPUT  FOR  Cl-  TEST 
LOSS  AND  DAMAGE  DISTRIBUTION 


SECTOR 


I. 


WPN 

TYPE 

2 

3 

6 

13 

16 

21 

29 

32 

39 

43 

62 


TOTAL 

OAMAGED 

NUMBER 

BLUE  FOR 

NUMBER 

EXCEED 

THEATER 

COSCOM 

oiv 

OR  LOST 

LOST 

DAMAGED 

REPAIR 

REPAIR 

REPAIR 

93. 

93. 

0. 

0. 

0. 

0. 

9. 

9. 

0. 

0. 

0. 

0. 

5. 

5. 

0. 

0. 

0. 

0. 

7. 

7. 

0. 

0. 

0. 

0. 

6. 

3. 

3. 

1. 

1. 

1. 

7. 

2. 

5. 

3. 

1. 

1. 

4. 

1. 

3. 

2. 

1. 

0. 

7. 

7. 

0. 

0. 

0. 

0. 

5. 

5. 

0. 

0. 

0. 

0. 

3. 

0. 

3. 

0. 

0. 

3. 

2. 

2. 

0. 

0. 

0. 

0. 

RED  FORCE 


WPN 

TOTAL 

OAMAGED 

NUMBER 

NUMBER 

TYPE 

OR  LOST 

LOST 

DAMAGED 

1 

2. 

2. 

0. 

■? 

4» 

112. 

112. 

0. 

3 

74. 

74. 

0. 

6 

74. 

74. 

0. 

11 

2. 

2. 

0. 

13 

4. 

i4. 

0. 

16 

6. 

0. 

6. 

21 

6. 

0. 

6. 

29 

3. 

0. 

3. 

31 

6. 

0. 

6. 

37 

2. 

0. 

2. 

39 

1. 

0. 

1. 

43 

5. 

0. 

5. 

50 

1. 

0. 

1. 

62 

2. 

0. 

2. 

63 

2. 

0. 

2. 

Figure  C-3.  Loss  and  Damage  Distribution 
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3. 

1. 

1. 

3. 

1. 

1. 

1. 


REPAIRABLE 
WITHIN 
5  DAYS 
0. 

0. 

0. 

0. 

0. 

0. 

2. 

2. 

1. 

2. 

1. 

0. 

1, 

0. 

1. 
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1. 

1. 
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1. 
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Table  a. 

ONE  SECTOR  OUTPUT  FOR  Cl-  TEST  :  SECTOR 

BLUE  LOSSES  BY  SOURCE  OF  LOSS 


VICTIM 

TYPE 


43 

62 


TNE  CBT  LTATG.M 


GND 

ATOM 


INF/CAV 

VEHICLE 


MECH 

ATGM 


2 

5.0 

10.0 

3 

1.0 

3.0 

6 

' 

13 

1.0 

16 

, 

2.0 

21 

1.0 

1.0 

29 

1.0 

1.0 

32 

• 

1.0 

1. 


TANK  MINES 


VICTIM 

INO 

SHORAD 

LRAD 

TOTAL 

TYPE 

FIRE  AO  GUN 

MSL 

MSL 

ATK  HEL 

TACAIR 

2 

16.0 

4.0 

56.0 

5.0 

93.0 

3 

9.0 

6 

5.0 

13 

6.0 

7.0 

16 

4.0 

6.0 

21 

4.0 

1.0 

7.0 

29 

2.0 

4.0 

32 

6.0 

7.0 

39 

5.0 

5.0 

43 

3.0 

,  3.0 

62 

2.0 

2.0 

Figure  C-4.  L'.sses  by  Source  of  Loss  (continued  next  page) 
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Table  d 
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Figure  C-4.  Losses  by  Source  of  loss  (concluded) 
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Figure  C-5.  Killer-Victim  Matrix  (continued) 
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Figure  C-5.  Killer-Victim  Matrix  (continued) 
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Figure  C-5.  Killer-Victim  Matrix  (concluded) 
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Figure  C-6.’  Ammunition  Expenditure  (continued  next  page) 
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Figure  C-6.  Anwunltlon  Expenditure  (concluded) 
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Figure  C-7.  Ratio  Statistics  (continued  next  page) 
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Figure  C-7.  Ratio  Statistics  (concluded) 
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APPENDIX  D 

THE  AUTOMATIC  LOADING  PROCESS 

D-l.  PURPOSE  ANO  SCOPE.  The  current  gamer  practice  for  loading  forces 
Into  a  sector  Is  to  use  an  answer  file.  This  appendix  describes  this 
process. 

D-2. •  GENERAL.  Answer  files  for  each  sector  are  prepared  in  editor  and 
catalogued.  When  the  forces  are  to  be  loaded  In  a  given  sector  the 
appropriate  answer  file  Is  attached  and  a  special  "load"  call  file  Is 
executed. 

D-3.  "CALL"  FILE.  An  example  of  load  call  files  Is  given  below.  Before 
executing  this  call  file,  the  answer  file  would  be  attached  with  "A*  as 
its  local  file  name. 

CONNECT, INPUT.OUTPUT 

ATTACH, JIFFY, E3BINSEG, ID-SCORES, MR-1. 

ATTACH,TAPE55,FORCEFIL£,ID-XJIFFYM. 

ATTACH ,SEG , SEGMENT , ID-X JIFFYM ,MR-1 . 

SEGL0A0.1-SEG. 

JIFFY, A. 

D-4.  ANSWER  FILE.  An  example  of  an  answer  file  run  Is  shown  In  figure 
0-1.  This  run  loads  all  units  of  parent  1  and  unit  21  of  parent  2  Into 
sector  7  of  Cl  test. 
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Figure  0-1 


Answer  File 


APPENDIX  E 

RUN  MODIFICATIONS  FOR  BATCH  PROCESSING 

E-l.  PURPOSE  AND  SCOPE.  This  appendix  addresses  the  requirements  for 
processing  the  Jiffy  Game  programs  in  a  batch  operating  mode.  Necessary 
program  modifications  and  procedures  for  completing  a  batch  run  are 
described. 

E-r2.  GENERAL.  Oesigned  to  be  an  interactive  computer  model,  the  Jiffy 
model  and  all  its  associated  programs  require  many  Inputs  during 
execution.  Ideally,  inputs  are  entered  by  the  user  from  a  remote 
Interactive  terminal  as  the  program  Is  being  run.  However,  there  are 
several  classified  data  arrays,  stored  in  the  computer  external  to  any  of 
the  coded  programs,  which  must  be  accessed;  and  security  restrictions 
prevent  access  of  these  data  from  some  of  the  remote  terminals  currently 
available  to  Jiffy  Game  users.  To  overcome  this  problem,  a  capability  has 
been  developed  for  processing  the  Jiffy  Game  In  a  batch  operating  mode 
without  entirely  sacrificing  the,  interaction  between  the  user  and  the 
game.  The  processes  involved  are  diagrammed  in  figure  E-l.  The  force 
file  building  process  Is  impacted  only  minimally  when  the  classified  data 
are  not  accessible. 

E-3.  DATA  REQUIREMENTS.  It  is  only  the  requirement  to  access  a 
classified  data  file  that  prevents  interactive  processing  of  the  Jiffy 
Game  programs  on  a  nonsecure  terminal.  None  of  the  coded  programs  contain 
classified  information,  nor  do  they  create  any  classified  files  or 
output.  Since  it  Is  the  numbers  In.  the  data  arrays  that  are  classified. 

It  has  been  possible  to  create  an  "unclassified"  data  file;  that  Is,  a 
file  containing  meaningless  data  values  but  paralleling  the  real  data  file 
in  .every  other  respect.  With  an  unclassified  file,  the  entire  Jiffy  Game 
can  be  processed  interactively  from  any  remote  terminal.  Obviously,  the 
results  obtained  by  doing  so  are  meaningless,  but  this  capability  plays  a 
key  role  In  creating  a  batch  run. 

E-4.  FORCE  FILE  CREATION.  The  force  file  building  procedure  discussed  In 
appendix  A  requires  processing  of  four  programs.  Of  these,  only  one,  tne 
FORCE  program,  requires  access  to  the  classified  data  file  (CLDATA).  The 
SRCFILE,  the  UNITFILE,  and  the  PARENTFILE  all  can  be  constructed 
interactively  from  any  remote  terminal.  The  FORCEFILE  can  also  be  built, 
using  the  unclassified  data  file,  at  a  nonsecure  terminal.  Even  when  the 
FORCEFILE  is  developed  with  unclassified  data,  the  unit  records  created 
are  essentially  correct;  the  only  consequence  of  doing  so  is  that  the  unit 
effectiveness  values  computed  for  a  unit  must  be  reset  with  classified 
data.  A  separate  program,  called  RESET,  Is  used  to  make  this  one-time, 
correction  during  the  batch  processing  as  described  below. 


E-l 


Figure  E-l.  Jiffy  Game  Batch  Processing 


E-5.  ANSWER  FILE.  As  Indicated  In  figure  E-l,  It  Is  necessary  to  create 
a  file  containing  the  "answers,"  or  inputs,  required  during  execution  of 
the  Jiffy  Game  program.  This  ANSWER  file  Is  created  by  running  the  Jiffy 
Game  interactively  from  a  remote  terminal  and  inputting  a  "4"  when  asked 
to  "SPECIFY  PURPOSE  CF  THIS  RUN" .  This  causes  the  program  to  write  each 
response,  as  It  is  enterec  at  cite  terminal,  onto  a  local  file  called 
ANSWER.  During  this  type  of  run,  the  user  makes  essentially  the  same 
Inputs  demonstrated  by  the  sample  run  in  appendix  3.  Some  differences  may 
occur  in  the  combat  assessment  routines  (paragraph  B-6).  Since  most  of 
the  classified  data  are  used  In  the  combat  assessment  calculations,  the 
losses  computed  during  an  unclassified  run  ( 1 . e. ,  using  the  unclassified 
data  file)  have  no  meaning.  Therefore,  the  displays  of  rate  of  advance 
statistics  and  combat  losses  shown  In  figures  B-4  through  B-ll  are 
suppressed  during  an  ANSWER  file  creation  run.  Also,  any  Inputs  based  on 
losses  previously  calculated  either  are  not  made  or  are  automatically 
adjusted  during  ths  batch  run.  An  example  of  an  input  that  cannot  be  made 
during  batch  processing  is  found  in  the  attack  hell copter/ air  defense 
routine  (see  figure  B-ll).  Here,  the  sortie  abort  Input  is  made  only  when 
helicopter  losses  reach  a  certain  level.  Since  the  helicopter  losses 
during  the  unclassified  Interactive  run  differ  from  those  during  the 
classified  catch  run,  aborting  helicopter  mission  Is  automatically  done  by 
the  program  In  all  cases  when  losses  exceed  30  percent.  While  some  Inputs 
affected  by  calculations  made  in  the  program  cannot  be  deleted  (e.g. ,  the 
number  A/C  entered  Into  an  attack  helicopter  cell  as  In  figure  3-11,  or 
specifying  the  numbar  of  CLGP  missions  to  fire  as  In  figure  B-7), 
provisions  have  been  made  In  the  program  to  adjust  them  automatically,  if 
necessary,  during  a  batch  run.  After  the  program  has  been  ended,  the 
ANSWER  file  that  Is  created  In  the  local  file  area  must  be  catalogued  into 
a  permanent  file. 

E-6.  BATCH  RUN.  The  actual  run  of  the  Jiffy  Game  requires  transfering 
the  answer  file  via  tape  to  the  secure  computer  system,  or  punching  a  job 
deck  and  delivering  It  to  the  central  computer  system  or  site  for 
processing.  A  sample  card  deck  showing  the  commands  necessary  to  complete 
the  run  Is  given  In  figure  E-2.  Note  that  the  commands  used  in  this  job 
deck  are  basically  the  same  as  those  used  to  initiate  an  interactive  run 
In  the  RUNJIFFY  "Call"  file  (figure  A-l).  Here,  however,  the  ANSWER  file 
created  by  the  user  must  be  attached,  and  the  command  "JIFFY,  ANSWER"  not 
only  executes  the  program  but  also  directs  it  to  read  the  inputs  from  the 
ANSWER  file.  The  output  from  this  job  includes  everything  found  in  the 
sample  runs  and  outputs  of  appendixes  3  and  C. 


1.  Job  card... 

2.  Task  card... 

3.  ATTACH,  TAPE55,  (force  file)... 

4.  ATTACH,  CLOATA,  (classified  data  file)... 

*5.  ATTACH,  RESET,  (source  code  file)... 

*6.  FTN,  I-RESET,  L«0. 

*7.  LGO. 

8.  ATTACH,  TAPE8,  (history  file)... 

9.  ATTACH,  TAPE9,  (SRC  file)... 

10.  ATTACH,  ANSWER,  (answer  file)... 

11.  ATTACH,  SEG,  SEGMENT. 

12.  SEGLOAD,  I-SEG. 

13.  JIFFY,  ANSWER. 

14.  REWIND,  STATS. 

15.  COPY,'  STATS,  OUTPUT. 

16.  End  of  file  card. 

♦Required  only  if  the  Force  File  has  not  been  reset  or  Initially  built 
with  classified  data. 


Figure  E-2.  Sample  8atch  Run  Job  Oeck. 
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distribution  list 


No.  Of 

Organization  Cop-Ill 

HOOA  (SAUS-OR)  1 

Washlngton,  D.C.  20310 

HQOA,  USAMSSA  1  . 

CSmM-SSO-C 

Washington,  D.C.  20310 
Conriander 

US  Army  Training  and  Doctrine  Command  1 

Fort  Monroe,  VA  23651 

ATCD-SA  1 

ATCD-AO  } 

ATCD-C  } 

ATCD-AN-M  J 

Director  2 

USATRASANA 
ATTN:  ATAA-0 

White  Sands  Missile  Range,  NM  88002 

Commander  *2 

Defense  Documentation  Center 
Cameron  Station 
Alexandria,  VA  22314 

Corrmandant  * 

US  Army  Administration  Center 

ATTN:  ATZI-CO-SD 

Ft  Benjamin  Harrison,  IN  46216 

Commander  2 

USA  Logistics  Center 
Fort  Lee,  VA  23801 

Commandant  •  3 

USA  Field  Artillery  School 
ATTN:  ATSF-CD-OS 
Fort  Sill,  OK  73503 


F-l 


No.  Of 

Organization  Copies 

Commandant  3 

USA  Infantry  School 
ATTN:  AT5H-CD-CS 
Fort  8enn1ng,  3A  31905 

Commandant  3 

USA  Armor  School 
ATTN:  ATS8-CD-S 
Fort  Knox,  KY  40121 

Commandant  2 

USA  Aviation  School 
ATTN:  ATST-CTD-C  ' 

Fort  Rucker,  Al  36360 

Commandant  2 

USA  Engineer  School 
ATTN:  ATSEN-CTD-CS 
Fort  Bel  voir,  VA  22060 

US  Army  Research  Institute  -  Field  Unit  1 

Bldg  314 

ATTN:  ATZICA-OL 

Fort  Leavenworth,  KS  66027 

Commander  1 

USAFORSCOM 

ATTN:  AFQP-PL-WP 

Fort  McPherson,  VA  30330 

Commander  1 

USAXVIII  Abn  Corps 

ATTN:  ATSU-CD-CS 

Fort  Bragg,  NC  28307  .1 _ 

US  Air  Force  2 

Tactical  Fighter  Weapons  Center/SATC 
Nellis  AF8,  NV  89191 

Commandant  2 

USA  Signal  School 

ATTN:  ATZHCO-S 

Fort  Gordon,  GA  30905 
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Commander  1 

USA  Concepts  Analysis  Agency 
8210  Woodmont  Avenue 
Bethesda,  MD  20014 

Commander  1 

USA  Concepts  Analysis  Agency 

ATTN:  MOCA-WGR 

8120  Woodmont  Avenue 

Bethesda,  MO  20014 

Commander  1 

USAECOM 

Systems  Analysis  Office 
Fort  Monmouth,  NJ  07703 

Commander  1 

USA I SO 

ATTN:  IATTD-CS 
Fcrt  Oevens,  MA  01433 

Commandant  2 

USA  Air  Defense  School 
ATTN:  ATSA-CD-SC-S 
Fort  Bliss,  TX  79916  . 

Commandant 

USA  Intelligence  Center  and  School 
Fort  Huachuca,  A2  85613 


Commander 
USA  Combined  Arms 
Fort  Leavenworth, 
ATZLCA-ADC 
AT2LCA-SW 
ATZLCA-Dl 
ATZLCA-CO 
ATZLCA-CA 
ATZLCA-CI 
ATZLCA-FS 
ATZLTDA-OS 
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ATSI-CO-CS 
ATSI -CO-MS 


2 
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Organization 


Commandant 

USA  Quartermaster  School 
ATTN:  ATMS-AR-C 
Fort  Lee,  VA  23801 

Commandant 

USA  Transportation  School 
ATTN:  ATSP-CO-QR 
Fort  Fastis,  VA  23604 

Commandant 

USA  Ordnance  Center  and  School 
ATTN:  ATSL-CTD-TA,  and  ATSL-CLC-0 
Aberdeen  Proving  Ground,  MD  210C5 

Comnander 

USA  Institute  of  Military  Assistance 
DCOMDT,  Ciiibt  Tng  Oiv 
Fort  3ragg,  NC  28307 

C  cm  and  ant 

USA  Military  Police  School 
ATTN:  ATZN-COC-SC 
Fort  McClellan,  AL  36205 

Commandant 

Command  and  General  Staff  College 
ATTN:  ATZLSW-TA 
CGSC  -  Library 
Fort  Leavenworth,  KS  66027 

Oeputy  Commander 
USAMSAA. 

ATTN:  AMXSY-T 

Aberdeen  Proving  Ground,  MO  21005 

HQ  USARFUR/7A 
ODCSOPS  -  DS&T 
APO  NY  09403 
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Commandant 

US  Army  Chemical  School 
ATTN:  ATZN-CM 
'  Fort  McClellan,  AL  35205 

*  Commander  1 

U SACO EC 

ATTN:  ATEC-EX-E 
'  Technical  Library 

Fort  Ord,  CA  43941 
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